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ABSTRACT 


This project consists of a part of the building of a 
DBMS based on the relational model. The data base chosen 
was the personnel data base of the Army Officers. In this 
part, the data base structure was first organized in the 
third normal fom representation of relatione. The data 
was then validated and placed on the disk according to that 
structure. The system was implemented on TDCi-316. This 
project was part of a larger data base project. The other 
parts developed were: 

[a] Building of the Data Base 

[b] Information Retrieval from the Data Base. 

All the systems are written in the Basic Assembly language 
of the TDC-316. 



1. INTRODUCTION 


In this project we are going to consider data valida- 
tion in data base system. The data base structure was 
built on the relational approach. 

Since the first publication of Codd's work [l] and his 
later publications [2*3,4], the area of relational approach 
to data base management systems has been a hot bed of beehive 
like activities. Thlisfi approach has been now considered from 
practically most of the theoretical angles and a large volume 
of work carried out in all these directions. Date [5] and 
Martin [6] provide excellent treatment of these topics. 
Especially Date's treatment provides the best reference and 
utilised in this present work. The relational model has 
been proved theoretically to be superior to the other two 
approaches of hierarchical and netwoik or DBTG-.. But in one 
respect viz., implementation it is sadly lacking. While 
there are some good major implementations of the hierarchical 
type (IMS of IBM is a classic and successful example) and 
several on the DBTG- approach, there are still no major imple- 
mentations and very few minor ones based on the relational 
approach. Some of these are mentioned by OhamberJdLn [15]. 

This project was taken up with this specific aim in 
mind. We wanted to implement a data base management system 
based on the relational approach. Our desire was to probe 
behind the facade of theoretical impregnability and find 
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for ourselves the difficulties faced in its practical 
implementation. Since a major project of this sort could 
not he handled in such a short span of time by a single 
person, it was split into several sections, to be attempted 
for implementation by different persons. 

This section of the project, as mentioned earlier, 
deals with the data validation and determining the struc- 
ture of the data base. Data validation is a very important 
part of a DBMS, as we shall demonstrate presently* To do 
so, we would perhaps do well to go back a little and des- 
cribe how data base management systems came about in the 
first place, 

1-2. DEVELOPMENT OF DATA BASS TECHNOLOGY AND .ITS RELATION 

TO DATA VALIDATION 

Sibley [7] has described how and why this development 
came about. When computer age began the data processing 
continued in the same manner as in the previous eras, i.e., 
each program had its own set of data and was owner of this 
data. Any other user found it difficult to obtain, integrate K 
or transform the ’available 1 data for use in another program. 
Thus, every new need for data involved writing a new program 
to obtain the data before it could be processed by yet 
another program, and even then it was difficult to do so - 
the data formats were ’locked* in the original programs, and 
sometimes the original object codes had been lost. This also 
led to a large amount of duplication of data and effort and 




3 


also the programs were completely data-dependent. The essen- 
tial unavai lability of otherwise transferable data gave rise 
to the question: 

’Why not integrate the data?’ 

This led to the thought that integration, were it possi- 
ble, could be achieved by defining the data format, storing 
it as a ’data definition’ and allowing general-purpose ’data- 
base management’ software to access it. This gave rise to 
the concept of the generalized data-base management system. 

Next came up the question: ’Can we access this data through 
our current computer languages?’ 

Jnd another: ’Why not allow a higher level language 
for adhoc use of the data base?’ 

Though inefficient, the first prototype systems appeared 
very successful to users, and commercial systems started to 
appear. Then the first problems arose. 

The industry congratulated itself on reducing data redun- 
dancy and improving its availability, but it also introduced 
the potential for disaster. The first problem with integra- 
tion arises because the data base is now more vulnerable to 
destruction through machine malfunction, personal error or 
deliberate human tampering. The loss of ’quality’ in a data 
y base (including total desctruction) by any of these means 

may be considered a threat to the very existence of the organi- 
sation, because data is one of its more valuable assets. 
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'Integrity 1 techniques are therefore a necessity. 

We may look at it from another point of view. Lott 
[8] says that, in data processing, we should remind our- 
selves of the saying that 'anything worth doing is worth 
doing right. ' Our operations are costing us so much to 

perform, and we hope they are being relied upon by so many 
people, that we must satisfy ourselves that we are operating 
within reasonable limits of correctness* Manual systems 
can have thingggo wrong intentionally and unintentionally - 
the more we mechanize and convert to electronics, the faster 
certain portions are performed and the faster incorrect 
output can be developed if proper controls are not employed 
to catch and to prevent such errors. But we must be cautious 
to have the right mixture of controls} on the one hand we 
wqnt to catch (and preferably prevent) as many errors as we 
can: And on the other hand we want to keep the costs of 
control to a reasonable figure* We cannot afford cent per 
cent control. ■ Thus we arrive at the conclusion that one 
of the primary and yet most important requirement for a 
DBMS is the process of data validation. Wot only programs, 
but also the data they operate on must be made as nearly 
accurate as human frailty and economic conditions will allow. 
Unless the data, on which the required operations of the DBMS 
are to be performed, is reasonably pure, the value of the DBMS 
is greatly reduced. This is clearly spelt out by the acronym 
Q-ISO (standing for garbage in, garbage out) meaning that if 
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the daxa you feed into the system is trash, all you can 
expect out of the system is trash only. 

But possibly the most neglected objective of DBMS is 
the maintenance of quality. Problems relating to the quality 
of data and the integrity of systems and data go hand in hand. 

1-3. A SURVEY OP THE SOURCES OP ERROR MD THE METHODS USED TO 

CONTROL THESE 

The data used in a DBMS can be erroneous due to several 
reasons. Errors can creep into the data from various sources. 
Some of these e,re mentioned in Date [5] and will be outlined 
here with their methods of prevention wherever possible. 

(1) Error at source, i.e., where the data has been 
collected. This cannot be directly verified, so either it 
must be double-checked at the source or some such fool proof 
method used (generally non-existant ) for form design, data 
collection and coding, etc., that the errors are at once 
detected. 

(2) Error after entering the machine, due to hardware 
failure at any point in the system may be a source of error. 

For example, the channel used for data transfer from the memory 
to the disk packs or the tape units majr have one of the bit 
transfer lines out of order at any particular instant of time 
so that an error in that position may occur in some part of the 
stored data. Some of these errors are dealt with by the 
inbuilt mechanisms of the eystem itself, as the parity ■ checking 
mechanism in tape drives, etc. We may mention in this regard, 



the mechanism of error detection huilt into the disk drive 
controller of the TDC-316. It computes a Cyclic Redundancy 
Check sum Code (CROC) for every sector of data that it stores 
on the disk pack while the writing operation is going on. 

Next, when it is reading that sector of data, it recomputes 
the CROC and ne,tches it to its previously calculated value 
stored at the end of the sector, any discrepancy causing 
error to he indicated and the read operation aborted. 

(3) Human errors play a significant part. The error 
during the collection of data has already been mentioned. Other 
human errors may be on the part of a computer operator, a ! 

keypunch operator or a terminal user. A typical error due to 
carelessness of a computer operator, that frequently plagues 
our installation here, is that the tape drives are not cleaned 
properly before mounting the tapes. Then, if some impurity | 

such as dust particles were present the data stored may be 
corrupted. This may again be taken care of by the system, e.g. , j 
the IBM 7044 here gives IOBS errors in such cases generally. j 

i 

! 

The operator may carelessly not repeat the data cards which 
have given read-check at the reader, so that the data on these 
cards is not loaded into the system at all and if the data wq,s j 
being loaded according to some sequence, that sequence may be 
totally lost. This is very difficult to detect, unless a total 
dump of the data is taken and the sequence meticulously checked, 
involving a lot of effort and time. • 
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Human errors in keypunching are very much prevalent. 

These may he of several types, e.g»* transcription errors 
in which the digits are punched wrongly, transposition 
errors in which digit positions get interchanged, shift 
errors by which a number like 24540 may be punched as 245400 
(left shift error) or as 2454 (right shift error), etc. An 
example of the last type of error can very easily occur 
during formatted EORTRAH I/O. The most prevalent amongst 
the keypunching errors are .the single transcription (one 
digit punched wrongly) and single transposition (a pair of 
digits, generally adjacent, getting interchanged). These 
two together account for nearly 90 percent of the keypunching 
errors. 

As Emery [143 has described, these errors may generally 
be checked at source. One process suggested by him is to 
prepare punched cards and punched paper tapes twice, inspite 
of the added expenditure, and then compare them .to eliminate 
errors. Another process, in common practice, is to use the 
dual process of punching and verification. A surer method of 
course is to use some form of error detecting code, like the 
modulus 11 code, when writing down the data itself. But these 
have two serious drawbacks. One is that it involves a large 
amount of computation to find the check digits themselves* 

The other is that it again involves human computation and so 
introduces new chances of error; But when taking the output 
from the computer, to be used subsequently as input at some 
later stage, these codes may be utilized. 
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Error possibilities exist even in the case of terminal 
users, but their probability of occurrence is very low and 
the possibility of early detection and correction is very 

high, so these need not be considered, 

( 4 ) Programing errors in the DBMS or the underlying 
opera-ting systems may be another source of error. We can 
take a simplified example. Let there exist in the DBMS a 
program that maps the logical record by its primary key to 
some physical record position on the disk. Let us assume 
that the program takes the help of a random number generator 
in achieving this mapping. Now if there are bugs in this 
random number generator (though such a case should not 
normally occur), then it may very well map the record onto 
some position on the disk while writing and then when re- 
trieval is being attempted, it might read some other record, 
even may be record of a totally different type which may 
then be corrupted through manipulation. The operating 
system may also, due to some internal bug, fail to attach 
the proper physical record sequence of track, surface, etc., 
for a particular logical record asked for, thus giving rise 
to error, 

(5) Programming errors in the data base application 
programs constitute another source of error. These may very 
well cause data corruption, A program may, while manipulating 
with the data, plane the fields in some wrong sequence or it 
may add the wrong things to the wrong fields or it may even 
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access wrong portion of the data base hy giving wrong identi- 
fiers for the files, records, etc. The last error is generally 
prevented "by adding security locks to the different portions 
of the data base. 

(6) The last source of error mentioned by Date is valid 
for a shared multiple-user system. In such a system, it is 
always possible that two or more users may have access to the 
data base at the same instant of time, and that the same record 
may be updated by different users at the same time differently. 
For example, in a real time airlines reservation system, say 
the number of seats available on a particular flight on a 
particular day is five, at a particular instant, and two reser- 
vation clerks from two different booking centres attempt to 
book four and three seats respectively, at the same instant. 

It may in such a case very well happen that two seats may be 
booked in the name of both the parties, creating confusion and 
trouble at the time of boarding. This will even harm the 
good name of the company. This type of error may be avoided 
by allowing access to a particular record by a single user 
only, at a particular instant of time, i.e., allow resource 
locking, so that when he is accessing that record, the other 
requests to that record are queued up, to be served later* 

Or it may suit the policy of the company to accord different 
levels of priority to different centres, so that, except while 
a disk write operation is in progress, the centre with higher 
priority will push out the others which may be using the system. 
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The first source of error, as we have already described, 
cannot be eliminated by any f&ol proof method. The method 
for reducing the second source, namely hardware malfunctioning, 
has been described in great details by G-otlieb and Hume [9]. 

These methods, though of long time past, are still valid. But 
since this is not of great importance to our discussion here, 
we will deal only briefly with it. 

A machine’s freedome from malfunction is the responsibi- 
lity of the manufacturer and maintenance engineer, but since 
the ultimate responsibility for accuracy lie with the progra- 
mmer, machine reliability is his concern also. Though there 
is no standard measure of reliability, Mean Time between Failures 
is assumed to be the standard. During daily maintenance, 
standard programs, which test different part of the machine are 
run. The hi gh- speed store, the magnetic drums and disks, the 
tape units, the input output facilities are all tested with ■ 

patterns of standard data to provide results which can be 1 

easily verified. Another kind of maintenance test of considers- j 
ble value is marginal checking, first introduced by the group 
on Whirlwind Computer at MIT. Different sections are run under 
conditions much more severe than would be expected in a normal j 

i 

run. Faulty components fail and are replaced. This method j 

I 

has become somewhat absolete due to the high costs involved 
and with the advent of more advanced technologies like TT1 
circuitry. ! 
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Wilkes [lO] has dealt with the particular case of main- 
taining integrity of a data base in the case of hardware fail- 
ures, Again we are not able to go into the details, but must 
discuss briefly the main points observed in his treatise. 

According to him, there is only one way whereby a high 
degree of integrity nay be achieved in any filing system and 
this is by keeping a copy of the information to be safeguarded 
in a separate place, or better still by keeping several copies 
in several separate places. This, being a very costly affair, 
cannot really be per sued in a large data base system. Next 
he suggested the process of incremental dumping. Here, any 
new file created or every new version of a file is only dumped. 
Even this becomes very costly and so can rarely be used. 

For large data bases, that have been in existence for 
some time, it is usually not possible to completely regenerate 
the system after error*, it must however be possible to repair 
the data base after an error has been detected. When mag tapes 
were used for staring the data, it was subdivided into reels, 
etc., so update or the problem of integrity could be handled 
in a much simpler manner. But, with the present data bases 
on direct access media, the problem is complicated by the 
fact that the need for rapic access with a minimum searching is 
leading to the use of highly complex data structures, so that 
there is a problem of maintaining the structural consistency 
of the data base as well as of maintaining the accuracy of the 
stored data. 
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Eext he made an attempt to classify and assess the 
measures that can he taken to monitor the operations being 
perfomed on the data base, so that, if information is lost, 
either the system can recover it automatically, or the user 
can be' assisted to do so« The measures were: 

(a) "Verification of operations with immediate 
repetition if in error. 

(i) Checks for transient hardware failures 

(e.g. , when writing on mag tape). 

5 ii ) Checking of keyed information 

(a) against internal consistency 
(this implies some redundancy 
in the keyed information). 

(b) against previously recorded infor- 
mation, 

(c) for reasonableness. 

(B) Redundant (error correcting) coding of information 
in the data base. 

(C) Periodic dumping of the entire data base. This, 
as pointed out above, is costly and not feasible 
for large data bases. 

(D) The use of journal tapes on which the Information 
is dumped continuously, while the system is in 
operation. 
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(i) Transaction journals: 

(a) A record of all key strokes made by 

keyboard operators, editing being either 
nonexistent or restricted to the deletion 
from the journal of errors that are imme- 
diately corrected. 

(b) A condensed summary of the transaction 
recorded immediately before the update 
is made. 

(ii) Record journals: 

(a) before journals, records are dumped before 
updating. 

(b) after journals, records are dumped after 
updating. 

It whould be noted that the effect of a system failure can be 
to cause an entry in a journal to be incorrectly terminated. 

The software should be so designed that it is still possible 
to read the other records on the tape. 

For /very large data bases, (G) is impractical, so editing 
of journal tapes is a must. Also, the use of (C) and D(i) 
makes D(ii) redundant. Greater control should be exercised 
by the DBA so that consistency can be more easily maintained. 

The third source of error, namely, human errors have 
already been dealt with. Fox programming errors in the DBMS 
or the underlying operating systems, again one of two procedures 
are suggested by Gotlieb and Hume [9]. One is to use checking 
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routines as a monitor during the operation of the program. 

The other is to use checking routines as a post-mortem or 
memory dump. 

Bayer [ll] deals with inte grity from the software point 
of view. He says that the proper use of the system is mainly 
concerned with quality control in data acquisition and with 
prevention of accidental or mischeavous misuse, i. e., with 
the security of the system. Bata bases give rise to especia- 
lly high integrity requirements for at least the following 
re asons: 

[1] Longevity: Even rare errors in the long rum will 
lead to a contamination and deterioration of the quality of 

a data base. Completely purging erroneous data and all their 
consequences from a data base is difficult. 

[2] Limited repeatability: Even if data or processing 
errors are discovered, it may be impossible or us&less to 
rectify the situation due to time constraints, unavailability 
of the correct source data, unavailability of the correct 
system state preceding the fault, etc. 

[3] The need for permanent and immediate availability: 
This prevents the common practice in other spheres to run a 
program, debug it, rerun it and so on, to be applicable here. 

[ 4 ] Multiaccess: Bata bases are manipulated by many users 
having probably quite different quality standards. It is 
infeasible to completely entrust the quality control to these 
users and difficult to track the source and the proliferation 
of errors. 
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Distinction can be drawn between two forms of integrity, 
namely semantic and operational integrity. 

Semantic Integrity : This is defined as the compHaLnce of 
the data base contents with constraints derived from our know- 
ledge about the meaning of the data. Semantic integrity might 
be enforced by allowing on certain data, only a limited set of 
precisely defined, meaningful operations, by adopting a set of 
programming and interaction conventions, by dynamically checking 
the result of the updates, or by proving for each program 
manipulating the data, base, that the semantic intetrity cons- 
traints are satisfied. 

Operational Integrity : Integrity of a data base must be 
guaranteed at the beginning and again at the end of transaction, 
it may be - and generally must be - violated by the single 
actions. Due to potential interfence between two or more 
transactions executing in parallel, transactions must lock 
certain parts for exclusive or shared use. 

He then described some algorithms for maintaining opera- 
tional integrity during parallel operation and resource sharing*, 
involving resource deadlocks and their prevention. We will not 
discuss the algorithms here. 

1-4. QEN3RAL VALIDATION REQUIREMENTS 

The basic process of data validation may be incorporated 
at three primary sections of the DBMS. These are as follows: 
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(1) Data validation is highly essential, we may say of 
critical importance, when we are constructing the data "base, 
i.e., creating the data for the relations which will constitute 
the data base on the disk pack. Here is the acronym G-IGO, 
mentioned earlier, most appropriate, and so great; care must he 
taken to place only correct (as far as possible), validated 
data into the data base. The same norms apply when we want 

to insert new records into an already existing data base. 

(2) When we are retrieving a record (or a set of records) 
for subsequent manipulation, report generation, etc., we need 
to validate the data. 

(3) When updating an already existing record, we need to 
validate the updated fields of the record, to check whether 
they cross the acceptable limits and so on, before writing them 
back onto the disk. 

We will now discuss some of the points where data valida- 
tion is felt to be necessary. First we will enunciate some 
of the principle points which are valid for any type of data 
base structure as obtained from Rajaranan 1 s notes [12]. They 
ares 

(1) Primary edit: In this portion of the data validation: 
procedures, the format, i, e. , the character type and lengths of 
the fields are checked. If a record fails to pass this test, 
it is rejected. Only after this test has been passed is the- 
re cord presented for the next phase of validation. 
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(2) Secondary edit: These may fall under several sub- 
sections: 

(a) The values of the data items in some of the domains 
may lie within certain hounds. These are checked. 
These fall under limit and plausibility checks. 

(b) Some of the fields may be related with one another 
by some form of relationship. These may be checked, 

(c) There may be control totals inserted at the end of 
the records or a set of records after being calcu- 
lated off-line. These need to be verified. 

Finally, we come to the relational model of data base or- 
ganisation and the different validation requirements for the 
data in such a model. Most of these are, of course, also valid 
for other models. Date [ 5 ] suggests the following requirements 
for validation: 

(1) When inserting a new record (or tupiie) into the data 
base, the primary key values in that relation are checked to 
see that the value of the primary key in this tuple is not 
equal to an already existing value in the tuple occurrences in 
the relation, for primary key value in a relation must be unique 
and so whenever duplication in this domain (or set of domains} 
is detected, an error signal must be given and operation 
aborted. 

(2) This same check must be applied to all the candidate 
keys in all the relations, for these again must have unique 
values • 
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(3) Again, this check must he made for all domains, or 
combination of domains (if any, at all), which are supposed 
to contain unique values. 

( 4 ) In third normal form in the relational approach of 
DBMS, all functional dependencies are eliminated, -except for 
the dependency of the non-key domains on the primary key. 

But there may still be nonfunctional dependencies, noted as 
cross references, as for example, the total amount of material 
issued out of a warehouse should not be greater than the total 
amount of material put into it. These constraints need to be 
validated. 

The validation requirements enunciated earlier for the 
general case are also valid here. 

Some of the procedures, which we feel would be useful 
in the above context are stated here. Bor example, it ■ 
would be very useful to have presorted relations, since in 
that case the time for search for a particular data entry will 
be greatly reduced, as we can use binary search procedures. 

It would specially be very useful to have an indexed sequen- 
tial organisation of the data base, with generally the 

primary keys acting as the index. In such a case, the index 
table may be brought Into main memory, for all the relations 
being currently accessed, and then a quick binary search of 
this table alone will help in locating the object of a query 
and also help in detecting duplicity in primary key, if and 
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when it occurs, so that an error message could be printed and 
action taken to avoid it. 

For the other candidate keys., we can again keep a direc- 
tory of these domains for a particular relation and sc check 
for their uniqueness from this directory. For all domains, 
or combination of domains (again, if any), besides keys, which 
are supposed to contain unique values, we can perhaps keep a 
flag where we define these domains, in the field list table, 

say, to indicate this special property of uniqueness. Then 
we can check these domains also for their uniqueness. This 
same procedure may also be adopted in the case of candidate 
keys other than the primary key. 

In the case of nonfunctional dependencies, we can utilise 
either of two modes of operation, either form • a sort of 
definition table where we name all the different domains which 
have any kind of nonfunctipnal dependency between themselves, 
together with the dependencies*, or we can each time specify 
these dependencies whenever we deal with the specific relations 
concerned and check for them. In the first method, whenever 
we come to the specific relation, we look up the particular 
definition table and finding the various dependencies, validate 
them by cross checking. In the second method, when we reach 
the particular position in the tuple, we are given the reference 
to check and we validate these. 
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Limit and plausibility chocks can be incorporated for 
specific domains at their particular positions in the typle, 
i.e., as and when we meet a domain for which limit or plausible 
value is specified, we validate it for this value without taking 
into account anything else like its position in the tuple, its 
relation with other domains, etc. Some of these can be express- 
ed as generalised relationships and can be verified by calls to 
generalised subroutines, if sufficient number of validations 
of a particular type are required. An example would be the 
plausibility checking of the different values of the years 
the different data fields in the data base. On the other hand, 
there are limit and plausibility check requirements for fields 
which appear only once in • each tuple of a particular relation 

in the data base. These checks can be incorporated in the form 
of open subroutines in the particular sections involved in the 
validation of those particular relations. 

The next chapter. Chapter 2, deals with the description 
of the personnel data bases which were selected for the data 
validation procedures. The various relations, the fields 
contained in these relations, their dependencies, choice of 
primary key and the reasons for the choice of the particular 
structures are described. 

Chapter 3 outlines the different validation requirements 
of the particular domains in the structure chosen. It also 
describes the various methods found suitable for use in these 


validat ions 
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Chapter 4 describes the different algorithms developed 
for satisfying the different validation requirements, as 
discussed in Chapter 3, 



2. NORMALIZATION OF THE PERSONNEL 
DATA BASE 

2-1. INTRODUCTION 

For a proper under standing of the process of data vali- 
dation, which is closely linked with the underlying struc- 
ture, i.e., with the data base we aim to validate, we would 
have to study this underlying structure. This chapter 
attempts to explain the context in which the data validation 
is proposed to be done, namely the personnel data base which 
needed to be validated and the basis on which its structure 
was built up. 

As mentioned in the previous chapter our aim was to 
implement a relational data base management system. For 
this purpose the data base had to be structured in the form 
of normalized relations. We will explain in the following 
section some points about normalization and the advantages 
of third normal form in which the data base structure was 

set up. Next we will explain some relevant points including 
the choice of primary keys, the reasons for the split up of 
the relations and so on. Finally, we will describe the actual 
relations themselves. 

2-2. NORMALIZATION 

The relational, approach to data base management is based 
on the theory of relations which gives it a sound theoretical 
basis a® mentioned earlier., Some valid points about this 
structure are: 
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(1) No two tuples (records) are identical in a relation 

(2) The ordering of rows (tuples) in a relation is in- 
significant. 

This shows that though a sorted relation is better in 
terms of query translation, sorting is not an essential part 
of the structure as such. 

(3) The ordering of columns (domains) is insignificant. 

This is true assuming reference is ms.de to individual 

columns by the appropriate domain names never by their relative 
positions. 

The above three points come naturally and are not very 
significant here. 

(4) Every value within a relation - i.e., each domain 
value in each tuple - is an atomic (nondecomposable) data 
item (e.g., a number or a character string). 

This means that repeating groups are not allowed for a 
domain value. A relation satisfying property 4 is said to 
be normalized and the relation thus obtained is stated to be in 
First Normal Form designated as INF. 

Now we define full functional dependence a concept impor- 
tant for the later forms. Given a relation R, we say that 
domain Y of R is functionally dependent on domain Z of R if 
and only if each Z-value in Rhas associated with it precisely 
one Y-value in R. Domain Y is fully functionally dependent on 
domain Z if it is functionally dependent on Z and not function- 
ally dependent on any subset of Z (it is assumed that Z is 
composite). When we talk now of functional dependence, we will 
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mean full dependence. 

We can now define second normal form or 2NF ass 
A normalized relation R is said to be in 2NF if and 
only if (i) it is in INF* and (ii) the non key domains of 
R, if any, are functionally dependent on the primary key of 

R. 

The 2NF data model suffers from anomalies with respect 
to storage operations very similar to those encountered with 
the hierarchical approach, namely those of addition, deletion 
and updating. These appear due to the fact that some of the 
non key domains are interdependent. By removing these inter- 
dependencies, we arrive at the Third Normal Form, or 3NF 
defined as: 

A normalized relation R is said to he in 3NF if and only 
if (i) it is in INF and (ii) the non-key domains of R, if any, 
are: 

(a) mutually independent 

(b) functionally dependent on the primary key of R. 

The 3NF representation has the advantage of removing all the 
three above stated anomalies. 

2-3. SOME GENERA! POINTS IN THE PROCESS OF NORMALIZATION 

Due to the advantages riientioned above, it was decided to 
implement the data base in the 3NF representation. We will 
discuss in this section o^her factors which led to the present 
structure. 
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We will first describe the intial layout of the data from 
which the data base was proposed to be built up. Figure 2-1 
gives a list of ell the fields with their serial numbers, names 
and character type end length. The data, arranged sequentially 
according to this figure, was originally obtained on a magnetic 
tape for 2000 officers from the Army HQ EEP Centre. But it 
was found that the ICL computer used to code the da.ta and load 
it onto the tape had a very much different character code to 
our IBM 70 44-1401 system through which the conversion of the 
data and its preparation of output as punched cards was proposed 
to be done (as the TDC-316, on which this project is proposed 
for implementation, has no tape units attached in the confi- 
guration available to us). So test data for 44 officers were 
prepared and punched manually and this was done for the diffe- 
rent relations in the data base in the final form which we will 
discuss presently. 

The most important criteria for the split up of the data 
base into the relations was to represent the data in 3NF. 
Another important criteria was the type of queries expected to 
be answered by the ^rstem. Figure 2-2 gives a list of typical 
and common queries, their periodicity and their distribution, 
i.e. , from whom it is generated and directed to whom, which 
determines its importance. 

From these queries as well as the layout of the data 
(in Figure 2-1), it became evident that all the tuples would 
have to be sequenced in terms of the domain called Personnel 



S.No 


Data Items 


Picture 


Zb 


1 

PARENT ARMS 

9(4) 

2 

PERSONS! NUMBER 

X( 7) 

3 

CHECK DIGIT 

A 

4 

FILLER 

X 

5 

USER-ARM 

999 

6 

TYPE OP COMMISSION 

99 

7 

FILLER 

X(6) 

8 

DATE OF SENIORITY 

9(6) 

9 

FILTER 

XX 

10 

SUBSTANTIVE RANK 

X 

11 

PRESENT RANK 

X 

12 

APPOmi'TiITT 

999 

13 

DATS OF APPOINTMENT 

9(6) 

14 

SUS-NO. 

9(7) 

15 

COMMAND-CODE 

9 

16 

DATE OF TOS 

9(6) 

17 

MEDICAL CATEGORY 

9 

18 

DATE OF BIRTH 

9(6) 

19 

MARITAL- STATUS 

9 

20 

DATE OF COMMISSION 

9(6) 

21 

TYPE OF CASUALIT':' 

9 

22 

NAME-F 

A.( 10 ) 

23 

NAME-S 

A(9) 

24 

FILLER 

X 

25 

SCHEDULE CASTE-TR.:EE 

9 


Figur 2-1. (cont’d) 
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26 

SS-EC-TO-IC 

9 

27 

FILLER 

X(6) 

28 

STATE-DISTRICT 

9(4) 

29 

CLASS-SUBCLASS 

99 

30 

DATS OF COMMISSION 

9<6) 

31 

DATS OF PRESENT COMMISSION 

9(6) 

32 

SECONDS D-TO-CODE 

X 

33 

FILLER 

2(4) 

34 

CAUSE -OF-NE 

99 

35 

DATE-OF-NE 

9(6) 

36 

NCC EXPERIENCE 

9 

37 

FILIER 

X( 22) 

38 

DATE OF SUBSTANTIATE RANK 

9(6) 

39 

DATE OF PRESENT RANK 

9(6) 

40 

AUTHORITY OF PRESENT RANK 

X(6) 

41 

PRE COMMISSI ON STAiTUS 

XX 

42 

OR- 

SERVICE 

X(5) 

43 

JCO 

-SERVICE 

X(5) 

44 

INSTITUTE OF COMMISSION 

9 

45 

TIME SCALE 

X 

46 

FILLER 

2(5) 

47 

RANK 

9 

48 

SHAPE 



’ (a) 

i S-VAL 

9 


h) 

I H-VA1 

9 


\o) 

1 A-VAL 

9 


(d 

1 P-VAL 

9 


(e 

1 E-VAL 

9 


Figu.’e 2-1 (cont’d) 
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49 S -BE TAIL 

(a) S-PBRIOD 99 

(b) S-MONTH X 

(c) S-Y3AR 99 

50 H-DETAIL 

( a) H-PBRIOD 99 

(b) H-MONTH X 

(o) H-YEAR 99 

51 A-BBTAIL 

(a) A-PERIOD 99 

(b) A-MONTH -X 

(c) A-YEAR 99 

52 P -DETAIL 

(a) P-PBRIOD 99 

(b) P -MONTH X 

(c) P-YEAR 99 

53 E -DETAIL 

(a) B-PERIOD 99 

(b) E-MONTH X 

(c) E-YEAR 99 

54 PST-M X 

55 VALIDATION CODE X 

56 CAUSE -OF-NE-EE-EMP 9(3) 

57 DATE OP KE-BE-EMP 9(6) 

58 OLD PERSONAL NO. X(8) 


Figure 2-1 
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Sr. No. 


Data I tens Piecture 


1 ARM SERVICE AND REGIMENT 9(4) 

2 PRESENT ACTING RANK 9 

3 PREFIX XX 

4 PERSONAL NO. 9(5) 

5 FILLER X(4) 

6 TYPE of cc:g:ission 99 

7 DATE OF SENIORITY 9(6) 

8 PRESENT SUBSTANTIVE RANK 9 

9 MED CAT (OLD FORMAT) 9 

10 DATE OF BIRTH 9(6) 

11 MARITAL STATUS 9 

12 DA*TB OF COMMN (FIRST) 9(6) 

13 NAME X( 20 ) 

14 FILI33R X(4) 

15 ACADEMIC QUALIFICATIONS 

(a) HIGHEST AQ 99 

(t>) PHD SUBJECT 99 

(c) MASTER DEGREES(2) 

(i) SUBJECT 99 

(ii) DIVISION 9 

(iii) FILLER X 

(d) BACHELOR DEGREE (2) 

(i) QFN CODE 99 

(ii) SUBJECT (I) 99 

(iii) SUBJECT (ii) 99 

(iv) SUBJECT (ill) 99 

(v) Percent MARKS 9 

(vi) DIVISION 9 

(vii) SUBJECT (IV) 99 


Figure 2-1 (cont'd) 



30 


16 

MEMBERSHIP OF INSTITUTIONS (6) 

X(3) 

17 

PROMOTION EXAMS 




(a) 

PART A 

(Now FILLER) 

X 


(1> 

PART A TECH 

X 


( cj 

PART B 


X 


(d 

PART C 


X 


(el 

PART C TECH 


X 


(fj 

PART D 


X 


18 PROFESS IONAL/TECHNI CAL QUALIFICATIONS (5) 


(a) QFN COPE 999 

M INSTITUTION 999 

(c) YEAR 99 

(d) SUBJSCT(I) 99 

Ce) SUBJECT (II) 99 

(f } MARKS 9 

(g) DIVISION 9 

19 LANGUAGES 

(a) FOREIGN (4) A 

(i) LANGUAGE CODE AA 

(ii) STANDARD 9 

(iii) PROFICIENCY 9 

(iv) FILLER X 

20 MOTHER TONGUE AA 

21 ARMY COURSES (15) 

(a) NAME X(4) 

(t>) GRADING XXX 

(c) YEAR 99 

(d) DURATION 999 

(e) FILLER XX 

22 HONOURS AND AWARD (6) A(4) 

23 QFN PAY 9 


24 MED CATEGORY 

(i) S (ii) H (iii) A (iv) P (v) E 9(5) 


Figure 2-1 (cont’d) 
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25 

DATE OF HE (IN HE -FIB ONLY) 

9(6) 

26 

DATS OF PRESENT ME 

9(6) 

27 

DATE OF SUB RANK 

9(6) 

28 

FIUER 

X(49) 


Figure 2-1 
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Number. This would he true for all relations in the data 
base. In many of these relations, this domain would be the 
primary key as well, satisfying the uniqueness property of 
primary keys. But in some of the relations it was also evi- 
dent that the Personnel Number alone could not serve as the 
primary key because the above mentioned constraint cannot be 
satisfied in these cases. let us take an example of such a 
relation. Let us take the case of an army officer possessing 
several civil qualifications like. B.A. , M.A. , L.LB., etc. 

For the sake of normalization, we would have to put each quali- 
fication in a separate tuple, yet each will be associated and 
primarily depend upon the Personnel Number of that officer only. 

So we would be repeating the same value of this domain in 
several successive tuples and hence by the property of uniqueness, 
it cannot be the primary key in such relations. It was found 
that a combination of this domain with some other domain, like 
the qualification code in the above case, could serve as the 
primary key in such relations, satisfying the criterion of 
uniqueness. In other relations, where only unique values 
could exist in other domains for a particular personnel number, 
like an officer’s name, date of birth, date of first commi- 
ssioning, etc., it was found possible to satisfy the constraint 
by this domain alone and this caused its adoption as the primary 
key in those relations. 

Thus we find that the choice of the primary key split the 
data base into two groups of relations, one with a single domain 
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S'l. 

No. 

Title of the Reports Periodicity 

( fhierie si 

Distribution 

1 

Actual strength of officers 
by parent arms/services and 
type of commission 

Monthly 

Org 2 

MS Coord 

ASO Man 

2 

Increase/decrease in the 
strength of officers by 
arms/service, type of commi- 
ssion and causes 

Monthly 

Org 2 

AG Budget 

ASO Man 

3 

Actual strength of officers 
by user/parent aras/services 

Quarterly 

Org 2 

ASO Man 

4 

Actual strength of officers 
by Arms/Services and Ranks 

Quarterly 

Org 2 

MS tfoord 

Mi see llane ous 

5 

Actual strength of officers by Yearly 
units 

ASO Man 

6 

Actual strength of officers 

Monthly 

ASO Man 


holding ERE unspecified 
appointment by arms/services 
and serving in regular army 
and other than regular army 
units 

7 Appendix (split by ranks) to Half- ASO Man 
actual strength of officers yearly 

holding ERB unspecified 
appointment by ana s/ser vices 
and serving in regular army 
and other then regular army 
units 

8 Actual strength of regular army Monthly ASO Man 
officers serving in TA by 

parent arms, commands and units 

9 Appendix (split by Ranks) to Half- ASO man 

actual strength of regular yearly 

army officers serving in TA by 
parent arms, commands and units 

10 Actual strength of officers Monthly ASO Man 

holding SI commission by user 
and parent arms and by regtt,, 

ERE specified and BEE unspecified 
appointment 


Figure 2-2 (cont'd) 
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11. Appendix (split by jranks less Half- ASO Man 

QMS and ROs) to actual streig£h yeprly 
of officers bolding SI» commi- 
ssion by user and parent arms 
and by Regtt. ERE specified and 
ERE unspecified appointments 

12. Details of changes in the stren- Quarterly PSS 
gth of officers by causes giving 
No., Name, Rank and effective date 
of change 

13. Actual strength of regular army Quarterly ASO Man 
officers with HQ and units of 
DQ-BR by ranks and commands 


14. Actual strength of ARC * s and Yearly Org 2 

BRO*s by arms/services and AG Budget 

classes ASO Man 

15. Nominal roll of PC officers Yearly MS3 

due for subs promotion 

16. Nominal roll of non- regular Yearly MS3 

officers due for promotion 


17. Nominal roll of officers (SL) Yearly MS3 
due for promotion 

18. Nominal roll of officers exclud- Quarterly PS5 

ing re-employed, RRO’s and TCOs ASO Man 

service in civil units and Mili- 
tary Missions abroad 

19. Actual strength of officers by year Qrtly. ASO Man 
of birth and year of seniority 

20. Actual strength of officers serv- Qrtly. ASO Man 
ing in army HQ, Inter services 

Organisations and Units, Ranks 
and Marital Status 

21. Nominal roll of officers placed Half DGAEMS (DG-3) 
in low medical category Yearly IMS 5 

ASO Man 

22, Actual strength of non-medical Half Org 2 

officers placed in low medical yearly IMS 3 

category by arms/Servlces, rank ASO Man 

and medical category 

23. Actual strength of Engrs, Signs., Half Org 2 

and EME officers by arms/ services, yearly ASO Man 
type of commission anc' educational 
qualifications 


Figure 2-2 (cont'd) 





24. 


25. 


26, 


27. 


Nominal roll of AMC, ADC Half 

officers "by units, ranks yearly 

and personal numbers 

Actual strength of officers Half 

by aims/services serving in yearly 

army HQ, Military Missions, 

commands and other miscella- 

neous units of the regular 

army 

Actual strength of officers Yearly 

belonging to SC/ST by arms/ 
services for regular and other 
than regular army. 


DMS1 
ASO man 


ASO Man 


ASO Man 


ASO Man 


Fresh- in- takes of officers be- Yearly 
longing to SC/ST by arms/ services, 
types of commission and state of 
domicile for regular and other than 
regular army during the year 1 Jan. 
to 51 Dec. 

28.. Nominal roll of regular army officers Half APS 


in personnel number order giving 
personal number, rank, name and 
present unit 

29. Nominal roll of officers possessing 
legal qualifications, by formations 


30. Actual strength of officers on 
X-list by arms/services, ranks 
and causes 


yearly PS5 
PS8 

Org Coord. 

Yearly JA& Dept. 

HQ comds. 
HQ Corps. 
Div. and 
Area HQ 


Half 

yearly 


ASO Man 


31. Nominal roll of regular army officers Half APS . 

in alphabetical order giving personal yearly Miscellaneous 
number, rank, name and present unit ASO Man 

32. Nominal roll of officers serving with Half AO Budget 
specified units and establishment yearly 

33. Actual strength of officers by subs Yearly MS Coord 

rank, type of commission, year of Org. 2 

birth and seniority combined and for ASO Man 

each separately 

34. Actual strength of substantive majors Yearly MS Coord 

and below by ranks, year of birth and Org. 2 

year of commission combined and separately ASO Man 
for each arm. 


Figure 2-2 (cont T d) 
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35. 

Actual strength by arms/ 
services and classes 

Yearly 

MS i 
Org 
ASO 

coord 

2 

Man 

36. 

Actual strength by arms/ 
services and marital status 

Yearly 

ASO 

Man 

37. 

Actual strength of officers 
by units and parent arms/ 

Half- 

yearly 

ASO 

Man 


services in HQ form, Misc. , 
Units and AEA units (for AHA 
units by parent arm, ranks in 
separate ppx) 


38. 

Actual strength of regular army 
officers in AHA units and X-list 
(separately) for regular and 
outside regular army units by 
parent arms 

Monthly 

ASO Man 

39. 

Actual strength of officers by 
present ranks and age groups 

Quarterly 

ASO Man 

i 

40. 

nominal roll of officers due 
for long service medal 

(a) 9-years 

(b) 20-yearB 

Yearly 

Org-3 

Org-9 

Med Dt. ; 

(for AMC/ 

ADO offrs) 

! 

41. 

Actual strength of officers by 
user arms /and present ranks 

Quarterly 

ASO Man 

42. 

Actual strength of offrs. by 
marital status for medical and 
non-medical separately 

Quarterly 

ASO Man j 

| 

1 

j 

43. 

All officers courses 

Yearly 

MS Branch j 

44. 

Strength of Engrs, Sigs. and 

BEE Offrs by qualifications 

Yearly 

MS Branch j 

Org. 2 

i 

45. 

PO Officers with 20 years 
service who have not passed 
part D examination 

Yearly 

MS 8 | 

i 

1 


Figure 2-2 
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as the primary key while in the other a combination of domains 
acted as the primary key. The consideration of the typical 
queries and their frequencies (in Figure 2-2) formed another 
basis for the division of the data. Final basis was the inter- 
dependence between non-key domains which caused further sub- 
division. The data base was split into twelve important rela- 
tions based on the above criterion, covering almost all the 
domains specified in the list of Figure 2-1. The few domains 
which were left out were ignored either because they do not 
form any part of the queries and were determined to be relati- 
vely unimportant or else thoir meaning was unexplained and 
possibly highly confidential. 

2-4. THE FINAL STRUG TUBE 

The greatest number of queries, with also the highest 
frequency rate, was observed to be according to the domain 
called Corps. So relation called AEM was formed having this 
domain as the major part of the primary key, thou^i the se- 
quencing of the tuples was still done according to the domain 
of Personnel Number which formed the minor part of the key. 

This relation is unique in this respect as in all the other 
relations. Personnel Numbers forms the primary key alone or is 
a major part of the primary key for the purpose of search for 
data retrieval. Rank and lime scale were the other two domains 
which were found to be related by queries to this relation and 
were thus added. This relation is shown as relation 1 in 
Figure 2-3. 
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Relation Is ARM 


Personnel 

No. 


Arms/Service 
or Corps 


Rank 

code 


Time Scale 


(7 bytes (2 bytes. (1 byte (1 byte, 

alphanumeric) numeric) numeric) alpha) 


IC-12343 


07 


3 

Y 


10-21001 


02 


5 

N 


Relation 

2s NAME 






Perso- 
nnel Name-S Name-F 

No. 

Date of 

bir fch 

Marital 

status 

”sc7~” 

ST? 

Reli- 

gion 

7 bytes, 
alpha- 
numeric 

Alpha- 

betic, 

16 bytes 

Alpha- Numeric 
betic, 6 

24 bytes bybes 

Alpha 

16 bytes 

Aljaha 

1 byte 

Alpha 

1 byte 

IC 10000 

RAINA 

THAR NARA- 25.11. 
SIMHA 

.22 y 

N 

H 

IC10060 

PATHAiC 

GOPAL 

SWARUP 

270324 

Y 7 

N 

H 


Perso- 
nnel No, 

Mother 

Tongue 

code 

Home 

state 

code 

If 

will 

made 

if if 

quali- honoured 
fied .. 

If Secon- 
ded to 

R and D 

IxV’ 

numeric 

Numeric 

2 bytes 

Numerio 

2 bytes 

Bach 

of length 1 byte and 
alphabetic 

type 

IC10000 

02 

01 

y 

y y 

N 

IC10060 

02 

01 

y 

N Y 

N 


Figure 2-3 (cont’d) 
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Relation 2: NAME 

Per so— if ~ legal i'oregin If No. No. 

nnel seconded quali- language member of of 

No. DG-I fication? known? of Inst, chil- depen- 

dren dents 

. ... Each of length 1 byte" and type Num. Nun. 

J alphabet ic 1 byte 1 byte 

1010000 N N Y Y 3 7 

IC10060 N N Y Y 2 4 


Relation 3: COMM 

Per so- Date oi£” Date of Date of P ire com. Other J CO Inst . 

nnel 1st change senior- status rank ser- of 

No. nnmm. to PC ity code service vice comm. 


7 bytes Num. Num. Num. Num. Num. Num. Alpha 

num^ bytes bytes bytes byte bytes bytes bytes 


I C 10050 

I C 1200 2 

510614 

520529 

510614 

570420 

490614 

520529 

1 2301 

8 2200 

0310 

0603 

IMA 

OTS 



Perso- 

If 

NCC 





nnel 

Re- 

experience 





No. 

enro. 






•r- •/ 

* t mm 

Alpha 

Num. 






1 byte 

1 byte 





IC10050 

':.Y 

200 




• 

IC12002 

-T 

100 
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Relation 4: QUA1 


Perso- 

nnel 

No. 

'Civil 

Degree 

code 

Main 

subject 

code 

Div. 

obtained 

Percent 

marks 

'tear 

passed 

out 

7 ‘bytes 

alpha- 

num. 

Nun. 

2 

"bytes 

Nun. 

2 

bytes 

• Nun. 

1 

byte 

Numeric 

2 

bytes 

Numeric 

2 

bytes 

IC31233 

07 

27 

2 

56 

58 

SS13987 

08 

21 

1 

79 

70 

Relation 5i 1ANGI 





Perso- 

nnel 

No. 

Code of 

Indian 

language 

Degree 

Profi- 

ciency 

of If Exam. 

I assed 



Alpha- 

nun. 

7 bwtes 

Nun. 

2 

_ bytea 

Nun. 

1 byte 

Alpha 

1 byte 



IC10100 

12 

4 

Y 



IC15400 

03 

5 

Y 



Relation 6: 1ANGF 


Personnel 

No. 

Code of 
Foreign 
language 

level of 

Exam. 

Passed 

Year 

Passed 

Alpha-nun, 
7 bytes 

, Hum. 

2 bytes 

Tun. 

1 byte 

Mum. 

2 bytes 

1030061 

03 

3 

57 

IC27001 

04 

1 

69 


Figure 2-3 (cont’d) 
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Relation 7: EQUAL 


Personnel 

No. 

trof . course 
code 

trading 

code 

Year 

Passed 

Alpha-num, 
7 bytes 

Rum. 

2 bytes 

Alpha 

1 byte 

Rumeric 

2 bytes 

IC10052 

11 

A 

60 

1012140 

08 

B 

54 


Relation 8: MED 


Personnel S H 


No. 

Irerioci Month Year Value 


'Year 

"value 

Alpha-num. All numeric 

7 bytes 2 bytes 2bytes 2b 

lbyte 

2byte 

All numeric 
2byte 2byte 

lbyte 

1019106 

15 02 76 

1 

14 

03 

76 

1 

SS13987 

15 02 76 

2 

15 

02 

76 

1 



MNHH 


P 




Period Month Year Value 

Period Month 

Year 

Value 


All numeric 
2bytes 2bytes 2byte 


All numeric 
2bytes 2bytes 2b 

1 byte 


15 02 76 

i 

15 

02 

76 

1 


15 02 76 

i 

15 

02 

76 

1 


S 

Period M onth Year Value 
All numeric 

2bytes 2bvtes 2bytes lbyte 
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03 
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1 
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Figure 2-3 Qcont’d) 
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Relation 9: UNIT 



13 ate of 
TOS 

Appt 

Code 

C xrom 
Exam. 

I) x-rom 
Exam. 

Substan- 
tive rank 
code 

Alpha- Num. Alpha 

num. 7 bytes 1 byte 

7 byt e s 

Num. 

6 bytes 

Num. 

1 byte 

Alpha 

1 byte 

Alpha 

1 byte 

Num. 

1 byte 

IC12408 0456654 S 

760809 

2 

Y 

N 

3 

SS16654 0632123 E 

760910 

3 

N 

N 

9 


Pereo- Date of 
nnel subs. 

No. rank 

I re sent 

rank 

code 

Date of 

Pr. 

rank 

”"OT ' 

Appt? 

TA 

Appt? 

Alpha- Num. 
num. 6 byte s 

7 bytes 

Num. 

1 byte 

Num. 

6 bytes 

Alpha 

1 byte 

Alpha 

1 byte 

IC12408 760712 

3 

760712 

Y 

N 

SS16654 760601 

9 

760601 

N 

N 


Relation 10: MINST 


Personnel 
No,. ... . 

Name of Instt. 
Code 

Type of ' Membership 
Code 

Alpha-num. 

Num. 

Num. 

7 bytes 

2 bytes 

1 — B — gSiE— 1 

! 

1024343 

13 

3 

SS13877 

21 

2 


Relation 11: KBMF 

Personnel New ter s. Date of Type of Oauxse of Rate of 

No. No, Retirement Release code Release reemploy- 
ment 

Alpha-num Alpha-num. Num. Num. Alpha Num. 

7 bytes 7 “bytes 6 bytes 1 “byte 26 bytes 6 bytes 

IC10000 ICIOOOO 760902 1 Age limit reached 760903 


Figure 2-3 (cont’d) 













Relation 12: RE COR 


Personnel 

No. 

Award Isfame 
Code 

Year 

awarded 

0 omnsnd 
Region 

Alpha-num. 

7 bytes 

Rum, 

2 bytes 

Mum. 

2 bytes 

Alpha 

1 byte 

ICIOOOO 

12 

63 

I 

SS12787 

06 

70 

C 


Figure 2-3 (ccnt’d) 



The next relation was called NAME and it contains all the 

personal details for a particular officer. Originally, it had 

been proposed that this relation should be broken up into two, 

named NAME and PEES, to cater to queries of two different types 

and frequencies. But since then it was found that domains like 

the officer’s address, his NOK's name, his address, etc., which 

were proposed to be put into the second of the two relations, 

namely PEES, and would have made the tuples of that relation 
quite long and so undesirable for retirieval every time, were 

not present in the supplied data domains. So the size of this 
relation was drastically reduced. There were also many domains 
common between the two relations so that it was now found viable ( 
as well as desirable for the sake of minimum data redundancy to 
combine the two relations and call it NAME. But we strongly 
recommend that the domains which were sought to be put into 
this relation and could not be because they were missing from 

the original supplied data should be included in the Army ! 

! 

Officers Eecords. The primary key in NAJME is Personnel Number. ! 
It contains all the personal details of an officer which could j 
be generally asked in a query and is the largest relation (in 
terms of tuple length) in our da.ta base. It also contains a j 
large number of pointer domains which indicate the presence of • ! 

i 

tuples in other relations. j 

Next came the relation COMM which contains the commission- 
ing details of each officer. Here again, since one and only 
one tuple exists for each officer, Personnel Number was suitable 
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as the primary Key* The other related domains* according to 
queries, were the Firsi-Date-of-CcmmisSioning, the i)ate«*of*- 
chah'ge-to-Pd, the Date-of*-seniority, Preoonmission status 

, ' V } 

code, OEr service, JCO-service, Institute of cbfmissioning, 
whether Re-employed ■ and ECO experience. They were assembled 
in the above given order in this relation* This relation is 
relation 3 in Figure 2«-3. 

Next comes the relation QJJAL, shown as relation 4 in 
Figure 2-3* This relation contains the civil qiialif ientions 
of the army officers* It was found* as discussed earlier* that 
a single officer may have several civil qualifications* So, 
in the case of this relation, the domain Personnel Eumber alone 
could not act as the primary key* But a Combination of this 
domain, with the domain for the civil degree code was fotfchd 
to contain unique values and since the other related domains 
were found to be functionally dependent on the combination it 

I , 

was found suitable to adopt this as the primary key for this 
relation. The other related domains were subject code* divi- 
sion, percentage marks and the year in which passed out* 
Presnece of a tuple in this relation for a particular personnel 
number is indicated by a pointer domain in the relation NAME 
called IF-Qual* 

The next relation in Figure 2-3 is relation 5 , named 
LAEGI* This relation Contains tfc§ details of the India* 
Languages known by the officers* Here again* for' reasons 
similar to above,- a combination of the domains of Personnel 



J. .VALIDATION HEQOI33:-jT27?S MB PROCEDURES 


3-1. INTRODUCTION 

We have already discussed, in the previous chapter, 
the various relations that were decided upon as the cons- 
tituents of our data base, together with the domain combi- 
nations in them. We also discussed the reasons whereof 
this particular structure was chosen and decided upon the 
domain or domain combination acceptable as the primary key 
for each relation. This arhapter attempts to describe the 
various validation requirements of each relation, first in 
general terms and then on a relation by relation basis, and 
the methods used in achieving these. As stated by Date [ 5 ] * 
it is not possible to check each and every item of data in 
a data base and maintain an absolute integrity. What has 
been attempted is to keep the data as error free as possible 
when storing it in the data base (in our case we had to 
assume that the data supplied was error free, because we 
have no means of checking back), to detect any e.rrors, if 
and when they occur, when we retrieve this data for subse- 
quent manipulation or report generation through simple but 
effective methods which would not require appreciable computer 
time or much extra storage space, and in the case of a few 
domains, where it was thought desirable to preserve a more 
rigid control on the integrity of the values of the data 
elements, simple coding was attempted in a form that 
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facilitated, error detection and in one single case also 
provided for error correction. 

Data need to be validated in four stages of a data 
base system implementation. The four stages are depicted 
by the block diagrams in Figure 3-1. As we observe here, 
the requirements for validation in the first and third 
stages, namely during initial data base building and during 
data storage after manipulation, are similar while those 
in the second and 4th stages, namely during data retrieval 
and for report generation are two complementary activities. 

So the validation would be treated as essentially parts of 
the first and second stages and differences, whenever they 
occur, between these two and the other two will be indicated. 

3-2. INPUT DATA VALIDATION 

3-2.1 Primary Edit : We will start with the discussion 
of the first stage. As we have noted earlier, in the first 
chapter, description of data validation must begin with the 
primary edit facilities provided by the system. . For our 
purpose we had chosen four allowable format types, namely 
decimal integer, binary integer, alphabetic and alphanumeric. 
These were allotted the code values of 1,2,3 and 4 respectively 
for input to the computer but inside the computer these were 

transformed to 0,1,2 and 3 respectively to conform to the 
format specifications being used by' the person utilising the 
data for the data base' BUILD function. The format specifica- 
tions for each relation was to be gLven in the form of 
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Number and code of language was chosen as the primary key* 

The other related domains were proficiency and whether an y 
examinations were passed in the subject. 

Relation 6 in Figure 2-3 is the relation MNGF, containing 
details of the foreign languages known by the army officers. 

Here again, to satisfy the property of uniqueness, a c ombina- 
tion of the domains of Personnel Number and the code of 
Language was selected as the primary key. The other related 
domains were the Highest-Examinat ion-Passed and the Year^Passed. 

Then came the relation PQUA1, shown as relation 7 in 
Figure 2-3. This relation contains a list of all the courses 
attended by the officers after commissioning in the army. 

Here again, the same difficulty as related to primary keys 
arose, as in the previous three relations, because each officer 
may and does attend a large number of courses and so in the 
normalized form Personnel Number is repeated as many times as 
the number of courses attended by the officer. A similar combi- 
nation of this domain and the professional course code, satis- 
fying the property of uniqueness, was chosen as the primary key. 
The other related domains were the Grading Code and the Year- 
Passe d-Out. 

Relation 8 in Figure 2-3 is the relation MED. This rela- 
tion contains the details of the medical biodata of the officers, 
i.e. , their medical fitness records. This relation can have 
only single tuples for each person and so Personnel Number could 
act here as the primary key. The medical fitness tuple for any 
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officer is split into five blocks, each block containing the 
four domains of Period, Month, linear and Value, in that order 
respectively. The blocks are named S,H,A,P and E, in that 
order respectively, giving rise to the acronym SHAPE. 

Herb to cone in Figure 2-3, is relation 9, called UHIT. 

This relation contains the details of each officer as related 
to the unit to which he is posted. Here again, each officer 
being related to one and only one tuple, personnel number was 
found suitable to act as the primary key. It contains besides 
the domains named SITS Humber, Command Region, Date-of-TOS, 
Appointment-code, C-Promot ions Examinations, D-Promotion-Exams. , 
Substantive Rank, Date-of-subs-Rank, Present Rank, Date-of- 
P-Rank, If-EHE-Appointnent and If-TA-Appointment. 

Relation 10 which comes next is called MIHST. This rela- 
tion contains the details of officers who are members of 
different Institutions and Socieities, professional and other- 
wise. Since the same officer could be member of several Insti- 
tutions at the same time, we were forced again to seek a combi- 
nation of the domains of personnel number and name-of-Institikte- 
code to act as the primary key. The only other domain found 
linked to this relation was the Type-of -Membership code and 
was added. This relation is again related to the relation 
HAME by means of a pointer domain in the latter relation. 

Relation 11 in Figure 2-3 is called REMP. As its name 
suggests, it contains the details of all officers who are 
reemployed after retirement by the army. The primary key in 
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this case is personnel number alone* The other domains are 
new personnel number, date-of-retirement, type- of— release, 
cause- of- re lease and the date-of-reemployment. 

The last of these relations of Figure 2—3 is relation 
12 called IECOR. This relation contains the details of all 
officers decorated for. showing efficiency in organization 
or bravery in the field of battle. Here again, a single 
officer could have obtained a number of decorations and so 
personnel number alone fails to be the primary key. A combi- 
nation of personnel number and the award name code satisfies 
the uniqueness property as well as the requirement of func- 
tional dependence of other domains and was chosen to play the 
part of primary key. The other related domains are those of 
year received and command region in which the officer was 
serving at the time of doc oration. 

Figure 2-4 gives a list of all the relations in a form 
of relation table. The contents of this table are the serial 
number of the relations, their names and all the identifications 
of the various domains contained in them. Figure 2—3 contains 
a list of all the domains in the data base in the form of a 
domain table. The contents of this table are the domain 
identifiers in serial order, their names, their types and their 
lengths. Figure 2-6 gives the list of other tables used in 
supplan-tting., some of the domains in the data base, i.e. , to 
define the various values and to give the meanings of the various 
codes used in the different domains of the data basei Finally, 
Figure 2-7 gives details oi these tables. 
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Relation Table: 

Code Relation Name Fields contained 


R1 

AEM 

R2 

NAME 

R3 

COMM 

R4 

QUAL 

R5 

LANGI 

R6 

1MGF 

R7 

PQUAL 

R8 

MED 

R9 

UNIT 

RIO 

MINST 

Rll 

BEMT 

R12 

DECOR 


F1,F2,F4,F6 

FI to F5,F7toF12, \F22-&oF28.3 

F1,F2,F4,F13 to F21 

F1,F29 t9 F33i - 

Fl,F34 y F35,I'36 

F1,F37,F38,F3S 

F1,F40,F41,F42 

F1,F43, to F62 

FI, F63 to F74 

F1,F82, F83 

F1,F75 to F79 

F1,F80, F81, F64 


Figure 2-4 



Sr 
I A 


Fane 


Type 


5U 


pi Personnel Fo. 


AH 

F 


ii 


F2 Rank 
F3 Fame-S 
F4 Arms/Service 
F5 Hame-E 
F6 Time Scale (T/F) 

F7 Date-of -Birth 
F8 Marital status (T/F) 

F9 If-Qualified (T/F) 

FIO If-on-Honours (Y/F) 

Fll If-seconded-to-R and 1 )(Y/f)A./f 
F 12 If-seconded-to-DGI (Y/F) A/F 
F13 Date-of-lst-commissioning 
F14 Date-of-change-to-PC 
F15 Date-of-seniority 
F16 rrecomm-status-code 
F17 Other-rank- service 
F18 JCO-Service 

F19 Institute-of-conmissioning 
F20 If-RE-EMTLOYBD (y/f) 

F21 FCC-Experience 
F22 If-SC/ST (Y/F) 

E23 Mother tongue code 
F24 Home state code 
F25 Religion 

F26 If -Will-Is-Made (Y/F) 

F27 If-Member-of-Any-Institute(Y/H) A/F 
F28 If-Having-Legal-Qualification (Y/F) A/F 


F 

A 

A/F 

F 

A/F 

A/F 

A/F 


F 
F 
F 
F 
F 
F 
A 

A/F 

F 

A/F 

F 

F 

A 

A/F 


F29 Civil-Degree -Code 
E30 Subject-code 
3? 31 Division 
3?32 Percent Marks 


F 

F 


E33 Year-passed-out 
P34 Code-of-Indian-language 
E35 Proficiency code 
1*36 If-Exam-Passed (Y/F) 

E37 Code-of-Eoreign-Language 

E38 Level-of -Exam-Passed 

P39 Year-passed 

5*40 Prof -course-code 

E41 Grading code 

1*42 Year-pa ssed 

E 43 S-Period 

E44 S-Month 

E45 S-Year 

E46 S-Value 

E47 H-Period 

E48 H-Month 

E49 H-Year 

p50 H-Value 


Length 


7 bytes (before) 

8 bytes (after) 

1 byte 
16 bytes 
1 byte 
24 bytes 
1 byte 
6 bytes 
1 byte 
1 byte 
1 byte 
1 byte 
1 byte 
6 bytes 
6 bytes 
6 bytes 
1 byte 
4 bytes 
4 bytes 

3 bytes 
1 byte 
3 bytes 

1 byte 

2 bytes 
2 bytes 
1 byte 
1 byte 
1 byte 

1 byte 

2 bytes 
2 bytes 

F 1 byte 

F 2 bytes 

F 2 bytes 

F 2 bytes 

F 1 byte 

A/F • 1 byte 

F 2 byte s 

F 1 byte 

F 2 byte s 

F 2 byte s 

A 1 byte 

F 2 bytes 

F 2 bytes 

F 2 bytes 

F 2 byte s 

F £ bytes 

F 2 byte s 

F 2 byte s 

F 2 byte s 

F 1 byte 


Figure 2-5 (cont’d) 
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F51 

A-Period 

N 

2 bytes 

F52 

A-Month 

N 

2 bytes 

F55 

A- year 

N 

2 bytes 

F54 

A- value 

N 

1 byte 

E55 

P -Period 

N 

2 bytes 

F56 

P -Month 

N 

2 bytes 

F57 

P-Year 

N 

2 bytes 

F58 

P -value 

N 

1 byte 

E59 

E -Period 

N 

2 bytes 

F60 

E -Month 

N 

2 bytes 

F61 

E-Year 

N 

2 bytes 

F62 

E-Value 

N 

1 byte 

F63 

SUS-No 

N 

6 bytes 

F64 

Comm and-Re gi on 

A 

1 byte 

F65 

Date of TOS 

N 

6 bytes 

F66 

Appointment code 

N 

1 byte 

F67 

F68 

C-Proinotion Exam. (Y/N) 
D-Promotion Exam. (Y/N) 

A/N 

a/n 

1 byte 

1 byte 

F69 

Substantive rank 

N 

1 byte 

F70 

Date of subs rank 

N 

6 bytes 

F71 

Present rank 

N 

1 byte 

F72 

Date of present rank 

N 

6 bytes 

E73 

ERE appointment (Y/N) 

A/N 

1 byte 

F74 

TA appointment (Y/N) 

A/N 

1 byte 

P75 

New Personnel No. 

A/N 

7 bytes 

8 bytes 

F76 

Date of Retirement 

N 

6 bytes 

E77 

Type of Release 

N 

1 byte 

F78 

Cause of Release 

A 


I' 79 

Date of Reemployment 

N 

6 bytes 

F80 

Award name code 

N 

2 bytes 

F81 

Year awarded 

N 

2 bytes 

F82 

Name of Institute code 

N 

2 bytes 

F83 

Type of membership code 

N 

1 byte 


before ) 
after) 


F28.1 Knowing foreign language (Y/N) A 1 byte 
F28.2 No. of children N 1 byte 
F28.3 No. of dependents N 1 byte 


Figure 2.5 
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Table of Tables 

Code 

T1 

T2 

13 

T4 

15 

16 
17 
IQ 

T9 

T10 

Til 

T12 


Name 

Rank Code 
Mother tongue code 
Home State code 
Preconn status code 
Civil degree code 
Main subject code 
Foreign- language code 
Professional- courses code 
Tupe of release code 
Award name code 
Name of Institute code 
Type of Membership code 


Figure 2-6 



Table Tl; Rank Table 
Rank Code Designation 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 


Table T12 

Code 

1 

2 

3 

4 

5 

6 

Table T5 
Code 

01 

02 

03 

04 

05 

06 

07 

08 

09 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 


General 
It. General 
Maj. General 
Brigadier 
Colonel 
Lt. Colonel 
Maj or 
Captain 
lieutenant 
Second Lt. 


Raj as than 
West Bengal 
Maharashtra 


Gujarat 

Orissa 

Assam 

Punjab 

Haryana 

Tamilnadu 

Karanataka 

Kerala 

Andhra 


Table T2 
Code 

01 

02 

03 

04 

05 

06 

07 

08 

09 

10 
11 
12 

13 

14 

15 

16 

17 

Table T5 


Mane 

English 

Hindi 

Bengali 

Tamil 

Telegu 

Kannar . 

Marathi 

Malayalan 

Gujarati 

Orriyya 

Assamese 

Gurunukhi 

Kashmiri 

Urdu 

Tarsi 

Sind hi 

Sanskrit 


Designation 

Code 

Degree Name 

Graduate 

01 

B.A. 

Fellow 

02 

M.A, 

Associate 

03 

B • Sc « 

Student 

04 

M. Sc. 

Pull 

05 

B.Com. 

Honorary 

06 

07 

M.Com. 

11. B. 


08 

B.E. 


09 

M.E. ! 

State Name 

10 

B.Tech. 

U.P. 

11 

M.Tech. 

12 

Ph.D. 

M.P. 

Bihar 

13 

Miscellaneous 


Table T7: 
Code 


01 
02 

03 

04 

05 

06 

07 

08 
09 

Himachal Pradesh 10 
Tripurr a 11 

J and K 12 

Arunachal 13 

Meghalaya 
Nagaland 

Union Territories 
and. Mi sc. 


Name of language 1 

Russian j 

German 

Trench j 

Chinese j 

Japanese I 

Spanish i 

T ortugue se j 

Arabic j 

Persian ; 

Greek i 

Italian 
Burme se 
Miscellaneous! 
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Table T8 


Table T4 


Code Name of Course Code 


Designation 


01 

02 

03 

04 

05 

06 

07 

08 

09 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 


I. Sc. 

1 

Student 

JC 

2 

Clerk 

EME Tels 

3 

Salesman 

Commando 

4 

Apprentice 

Sr. Camibjbssioning 

5 

Storekeeper 

Young Officers 

6 

Scientist 

JAWS 

7 

Engineer 

Paratroopers 

8 

Miscellaneous 

LG SC 

9 

Teacher 

PTSC 

Company commander 
Catering 

Table T9: 
Code 

Tvne of Release 

Intelligence 

IT 

1 

Normal Release 

Weapon training 

2 

Premature Retirement 

Snow warfare 

3 

Cashiering 

Mont ainob ring 

4 

Dismissal 

Short equipment 

5 

Medical 

Senior Ammunication 

Tech. Officers 


NDC 

Defence Mgmt. 
Work Study 
Tank Technology 
Miscellaneous 


Code 

01 

02 

03 

04 

05 

06 

07 

08 

09 

10 
11 
13 


N me of Award 


Ashok Chakra III 
Ashok Chakra II 
Ashok Chakra I I 

Shawraya Chakra 
YSM ! 

AVSM I 

PVSM | 

Mentioned in De.spatch ! 


SM 

VC 

MVC 

rvc 


Table 2-7 (cont’d) 
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Table T6 Table Til 

Code Name of the Main Subject Code Name of Instt ( or society 


01 

02 

03 

04 

05 

06 

07 

08 

09 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 


Economics 

English 

Philosophy 
Political Science 

Vernacular 

Physics 

Chemistry 

Mathematics 

Zoology 

Botony 

Statistics 

Geology 

Accounts 

Hydraulics 

Envir onme nt al 

Civil 

Aeronautics 

Chemical 

Mechanica 1 

Electrical 

Electronics 

Tolec ommunic at ion 

Architectural 

Naval architecture 1 

Mining 

Metallurgy 

Miscellaneous 

Computer Science 


01 

02 

03 

04 

05 

06 

07 

08 

09 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 , 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 


CSI 

IEEE 

Instt. of Eng g. (India) 

ASC 

IGS 

PIP 

I. Math. S. 

Aero Soc. of India 
All India Mgmt. Assoc. 
American A. for Ad. of Sc. 
Am. A. for Petroleum Geo. 
Am. Geographical Soc. 
AIChE 
AIEE 

A. Math. Soc. 

Am. Inst, of Chemists 
A.S. of Civil Engg. 

ASMS 

ASNE 

Asiatic S. of Bengal 
As. of Applied Physicisi 
ACM 

Calcutta Hist. Soc. 
Calcutta Math. Soc. 

Am. Inst, of Architects. 

Red Cross 

IFF 

IHF 

Indian S, of Civil Engg, 
III 

IIC and WA 
NIS 

Miscellaneous 


Figure 2-7 
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consecutive 3 digit decimal numbers for each domain, the 
first digit giving the domain type and the other two digits 
giving the length of the domain as the number of characters 
or bytes. Inside the computer, these format specifications 
wore stored in one word, with the first 4 bits of the word 
corresponding to the domain type and the rest twelve bits 
used for storing the length. 

Whenever data was being stored, either during the ini- 
tial phase of data base building or later when data, is being 
inserted into an already existing data base, the first card 
was used to specify the format of the relation being currently 
stored. These formats are suitably converted and stored by i 

a routine called PEFOEM. Next comes a card that gives the 

i 

number of records being stored in that relation and this was 
checked and stored by a routine called NOFKBC. Now, when the 
actual tuples of the relation are read in, they are checked j 

for format validity (according to format description stored j 

! 

by PEFORM) by a routine called PBCHECE. Any error during 

this primary edit procedure gives rise to an error message | 

and causes the offending tuple to be printed out as well. 

3-2.2 Pr imary Key Validation : At the next step we start 
our secondary edit procedures. The most important among these 
and one that concerns us in all the relations is the validation 
of primary keys to prevent their duplication. This was achieved 
in our case by a routine called PKCHEK. This routine compares 
the primary key of a tuple with the primary keys of the previous! 
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stored tuples, which are separately stored hy this routine 
itself, and if the key is found to he unique, it adds it to 
its storage of primary keys aad passes control hack to the 
main routine for further processing. In case of duplication 
occurring it prints an error message fillowed hy the offending 
t^ple and waits for restart so that the card containing the 
tuple can he replaced. In our case, the relations were 
structured in such a fashion as to prevent the occurrence of 
candidate keys other than the primary key, so there was no 
need of any other type of key validation. 

3-2.3 Validation of Some General Domains. : Next we come 
to a discussion of some particular domains or domain types. 
First, and foremost in our discussion must come the domain 
named Personnel Hunter. This domain is very important because 
os we found in the previous chapter, it forms a part of every 
relation in our data base and is the primary hey in many of 
these relations and is a vital part of the primary key in all ; 
tho other relations. This domain has as input a seven-byte j 
alphanumeric string, the first two bytes being characters from ^ 
the alphabet while the remaining five bytes are decimal digits.; 
The two-charaoter first section is chosen from a small set of j 
particular combinations of letters, and so can be easily vali 
dated. This is initially done by a routine called PHCT. Kent | 
the five-deoimal-digit section was coded in a simple manner j 
by another routine nmed FJTOC. This converted it to a si*- j 

digit figure instead of its original five bytes. This was , 

done with two specific aims in mind. One was to diffuse j 
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or scramble the value , so that without the help of the proper 
coding function, the data value in this domain cannot be 
matched and so the tuple cannot be retrieved. This would 
provide a simple method of preventing illegal access to the 
data as all accesses to the data base by primary key matching 
would be affected as this domain is the primary key or a 
vital part of it for all the relations in the data base, as 
discussed earlier. The second aim is to provide some measure 
of error detection capabilities, in accordance with the impor- 
tance of this domain. 

The domain or domain type considered the most important 
after this was the type of domain which contained the simple 
binary answer of Y or N (standing for Yes and No; respectively). 
This domain type was considered important for two reasons. 

First is its high rate of occurrence in our data base. A total 
of 17 domains out of a total of 83 domains, giving a proportion 
of 1 in 5 roughly, were found to be of this type. The other 
factor contributing to the importance of this type of domain 
is the fact that in many cases it acted as a pointer to the 
presence or absence cf tuples in other relations in the data 
base. 'He will illustrate this point with an example. In the 
relation called NiiME, there is a domain called If-Quelif ied. 
This is a domain of the above type, indicating whether that 
particular person has any civil qualification or not. The. 
value Y indicates the presence of at least one tuple having 
the same Personnel Number in the relation named QUAl. So when 
a query asking for personal details of the person also wishes 
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to find out whether he has any civil qualifications, and if 
so, what, the relation NA ME "being searched for the other 
details is also able to provide the answer to the first 
part of this query by indicating whether the person has any 
civil qualifications or not. In the case of a value of T N J 
in this domain, the QUA! relation need not be searched at 
all. This helps in reducing the time for fruitless searches 
and thus helps in quicker query translation. But if any bit 
position in this byte got corrupted, it will not be possible 
to get this query answered so easily and may even give rise 
to an erroneous answer. 

So the following simple method was utilized which made 
it possible not only the detection of error but error correc- 
tion as well. The domain is first checked to find out whether ' 

i 

it contains a Y or a N. Any other character in the domain 
gives rise to an error message. Next, for a value of 'Y 1 , the 
byte was replaced by a set of all l’s and for 'N* was replaced 
by zero. This requires no extra space for the same byte posi- j 
tion is utilized. Ill the above was achieved through a routine ; 

i 

called YNCON. Next when the data is retrieved, another routine . 

i 

named YNDECO checks whether the number of l*s in the byte is j 
greater than four or not. Bor all combinations in the byte j 

h 

having 1*8 in five or more bit positions, ‘Y* is assumed to be | 
the domain value and substituted and for all the remaining ; 

combinations, , N 1 is assumed to be the domain value and 
substituted. This simple yet effective procedure caters for } 
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anything up to three errors in any of the hit positions in 
the byte. The possibility of 8. higher number of errors 
occuring is considered to be negligible. 

5—2. 4 Con eral Conside rations in the Validation s Next 
wc should come to a relation by relation implementation of 
the data validation requirements and the procedures used 
in fulfilling then. We have attempted to code only the 
domains whore it was deemed extremely necessary, as stated 
before. I think a short explanation in lieu of this step 
is duo here. 

Originally it was thought that each individual domain 
should be coded so that at least error detection, and if 
possible also error correction would be facilitated. But 
later thoughts provoked us to decide in favour of attempt- 
ing to code as little as possible. It was determined that 
in the model of data base that we have chosen for implemen- 
tation, the queries, the type of domains and in fact every- 
thing indicated that the manipulations required to be per- 
foimed with the domains were very simple in nature, mostly 
involving transfer, comparison and input/output type of 
operations. It was also detemined that it would take a 
lot of computer time to convert the ASCII input to binary 
(in the case of decimal digit input), to code them for pro- 
viding error detection and correction capabilities and then 

for checking these functions during retrieval, to decode 
thorn and then finally to convert them back to ASCII for 
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printing. The saving in space due to conversion to binary was 
not appreciable and the error detection and correction capa- 
bilities provided were found to be too small a gain compared 
to the time required for such operations. So the idea of con- 
verting and then coding the numeric portion of the data was 
finally given up* Due to the difficulties faced in coding the 
decimal digits directly, this idea also was given up. 

Instead of these methods, another method was frequently 
used in this implementation. This method was to compute the 
chock sums of the numeric fields, sometimes position wise but 
generally digitwise and to append these check suns to whatever 
positions within the tuple found to be most appropriate (mostly 
these were appended ri^at at the end of the tuple). This pro- 
cedure was followed whenever fresh tuples having a large number 
of numeric fields was being stored. Next, whenever this data 
was to be retrieved from the relation for subsequent manipula- 
tion, the check suns can be (recomputed and composed with the 
previous value, and discrepancy giving rise to an error conui- 
tion, signified by the print out of an error message followed 
by the print out of the offending record. This method 
appeared to provide a fair measure of error detection capa- 
bility, though no error correction capability can be claimed. 
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by Relatio n Analysis of the Implementation : 
Wow we come to an actual relation by relation description of 
the data validation procedures implemented. In the first re- 
lation, named ARM in the previous chapter, we found that the 
corps domain was given as a two-digit decimal number. But 
for reasons of convenience in query translation, as desired 
by the person coaling with that part of the implementation, 
this domain was converted to binary and stored in one byte 
by a. routine called ARMCON, This is unique tc this domain, 
as it has been already explained that no other domain was 
converted to binary. The Personnel Number domain was suitably 
checked and coded. The domain of Hank does not merit any 
coding or validation. The only other domain in this relation, 
namely Time Scale, was a Y/N type of domain and was suitably 
validated and coded. 

In the next relation Name ; the Personnel Number, domain 
was validated and coded. The next two domains of Uane-S and IS 
Wane-P were left alone after primary edit. In the Date-of- 
Birth domain, the year portion was chocked for plausibility 
by means of a routine called YRLIM. The next two domains of 
Marital-Status and SC/ST are Y/N type of domains and were 
checked and converted. The next three domains were left alone 
after primary edit. All the next eight domains are of the Y/W 
type and were converted. The next three domains are again 
of a type that required no validation after primary edit. 

Since the number of numeric fields in this relation was small 



68 


Next relation QUA! is the first one which does not have 
a single domain as the primary key. Here a combination of 
the Personnel Number and the Civil- Degree-Code satisfies the 
constraint for uniqueness and was chosen as the primary key. 

This was validated after primary edit. The Personnel Number 
was then suitably coded. The year-passed- out domain was tested 
for plausibility using YRLIM. None of the other domains give 
rise to the possibility of validation and so were left alone 
nftor primary edit. But since all the domains are of numeric 
type, both the digitwise and positionwise checksums were compu— • 
tod and appended. This helps in detecting an error condition 
whenever it occurs in any of the actual domains but when an 
error has occured in any of the checksum domains (but not in 
both) the error is corrected internally so that processing 
can continue undisturbed. The checksumming was achieved by ; 

means of the routine QA1C0D. ■ 

The next relation liJJGI also has a combination of two j 

domains Personnel Number and the Language-Code as the primary 
key. This is validated after primary edit for the property j 
of uniqueness. The fourth field is of Y/N type and is oonvsr- j 

ted by YNCON. j 

In the next relation LANGF, we again have a combination j 

f 

of the Personnel Number and Language-code domains as the, j 

primary key. This is validated after primary edit. The fourty 
domain is the Year-Passed which is checked for plausibility 
through 1RL3M. All the other domains besides that of 
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Personnel Number being purely numeric, the positional se check 
sum was computed and appended to the end of the tuple by the 
routine FLCON. It perfomed the additional duty of checking 
for the plausibility of the third domain, namely the Highest— 
Exam.-Passed-Code. 

The next relation in our list is PQHAl. It again has 
a combination of two domains, the Personnel Number and the' 
Prof— Course-Code as the primary key. After primary edit, the 
primary key validation is carried out. Next the Grades domain 
is checked for the correct values as only four types of grades 
are allowed. The Year-Passed is next checked for plausibility 
through YRLIM. 

In our next relation MED, Personnel Number satisfies 
the property of uniqueness and so was chosen as the primary 
key. It w%s validated for the above constraint after primary 
edit. Next the Personnel Number domain was coded. Finally 
the control was passed to the routine MEDCOD. This routine 
computed the digitwise checksum of each of the S,H,A,P and E 
blocks and appended them after their respective blocks. It 
at the viune time computed the digitwise checksums of the 
different domain types, P,M.Y and V and appended these success- 
ively in the above order at the end of the tuple. This greater 
amount of trouble taken in this particular relation can be 
justified on the ground that any wrong information in this 
relation could cause premature retirement of an able-bodied 
officer as also the extension of service for some other person 
physically unfit for his job. 
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N ;xt relation UNIT also has Personnel Number satisfying 
the property of uniqueness and so chosen as the primary key 
and validated after primary edit, Next cones the SUS No. , a 
seven— digit decimal code which was left alone after primary 
edit. The next domain of the command- region was validated 
out of a fixed set of character strings by the routine COMCHK. 
The next domain of Date-of-TOS was validated for the plausi- 
bility of the year portion of it by YRLIM. The next domain 
was left alone. The next two domains are of the Y/N type and 
vrere properly coded after validation by YNCON. The next do- 
main of subs-rank was checked against the present-rank domain 
for validity. The year portions of the dates of subs-rank 
and present-rank were again checked for plausibility by YRLIM. 
The last two domains were again of the Y/N type and were 
suitably converted. 

Tne next relation of MINST has the combination of Perso- 
nnel Number and Institute-Code domains as the primary key. 

A fter primary edit, validation of the primary key was carried 
out. There is only one other domain in this relation and it 
requires no other validation than primary edit. 

The relation KEMP which comes next has unique tuples 
corresponding to personnel number which corresondingly could 
be taken to act as the primary key. It was validated after 
primary edit. The next domain of the new-personnel number was 
validated and converted, again by PNCON. The year value in 
the Date-of-Retirement (the next domain) was checked for 
plausibility by YRLIM, as also the year portion of the Date-of- 
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He employment, the last domain of this relation. The other 
domains were passed over after primary edit. 

The last relation in our present structure was DECOR, 
which again does not have unique personnel numbers for the 
tuples and a combination of this domain and the award-code 
domain was chosen as the primary key. This was validated 
aftei primary edit. The next domain of year was checked for 
plausibility by YR1IM, The last domain cf command-region was 
validated through the routine COMCHK. 

We had been discussing data validation with respect to 
the initial phase of data base building. Two other routines 
were heavily utilized in this phase, one for writing the data 
onto the disk and the other for selecting the area where the data 
is to be placed, i.e., for choosing the cylinder, surface and 
sector numbers and incrementing them properly after each write 
operation. The first is called WRITE and the second is called 
ARSLCT. iinother routine SET is used at the beginning of the 
whole operation for the purpose of initialisation, before any 
write operation is attempted. 

3-3. VALIDATION DURING RETRIEVAL \ 

| 

The next phase of data v alidation is done when a tuple is 
retrieved from the data base for the purpose of manipulation ; 
or report generation. Here again, for a particular query, a 
particular relation is chosen which contains the answer to the i 
query. This may involve several intermediate stages concerning ! 
several other relations* choosing different sets of domains and ] 
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so on from different relations until finally nil the condi— 
ticns specified in the query are fully satisfied. This also 
requires searching of these relations to find matches for the 
primary keys specified. This portion of the project falls 
under query translation taken up hy another member of the 
project group. In this phase he is supposed to utilise the 
routines developed for the purpose of data validation. 

The validation requirements in this phase were mainly 
concerned with the validation of the checksums to find out 
whether any portion of the data had been corrupted and listing 
out the error message together with the offending tuple in the 
case of its occurrence. Other possible validations were that 
of the primary key, the primary edit to satisfy that character 
type had not changed and the validation of some of the inter- 
field relationships. But these last portions are all optional, 
since we may assume that in case the checksums are validated, 
they are unlikely to occur and the other possible error, namely 
the duplication of primary keys is also unlikely in case the 
uniqueness constraint had been satisfied initially when build- 
ing the data base. 

The routines used at this stage for the checksum valida- 
tions will now be described. The routine COMES C calculates 
the checksums of the date-fields and the other numeric fields 
in the COSIM relqtiepc separately. It also sums these two 
checksums and then compares the three values with the three 
values computed earlier during the building phase and appended 
at the tail of the tuple. If either the first or the second 



73 


aisinEvtcb.es and the third is also found to he wrong, then 
error is indicated. But if either the first or the second 
mismatch but the third is found to be alright, then it can 
bo safely assumed that only the appropriate checksum domain 
has been corrupted and this is replaced by the correct value 
and the data presented for manipulation without an y error 
being indicated. 

In the relation QUAL, the subroutine QAIEEC performs 
a similar function. As described earlier, in this relation 
the digitwise and positionwise checksums of the numeric fields 
were computed and appended at the end. These are now re- 
computed and compared. Mismatch for both values indicates that 
error had occurred. But if only one value mismatches, then 
that checksum only has been corrupted and after its replacement 
by the correct value, processing of the tuple can continue. 

The routine FLDEC validates the relation LANG-F. Here 
again the positionwise check amis recomputed and compared with 
the previous value, any discrepancy giving rise to an error 
message. 

The routine MEDVAL is used to validate the relation MED. 

As discussed earlier, major efforts were put in-ctocompute the 
digitwise checksums in this relation* The checksums for each i 
of the five blocks were computed and appended at the end of 
that block while the checksum for each type of field was also 
computed separately and these were appended in tbe order of 
appearance of the fields at the end of the tuple. These are 
now recomputed and comparisons made. Any error in the actual 
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dot a items would give rise to discrepancy in two of the check- 
sum domains, one belonging to that block and the other to 
that type of field, A cross checking ensures that this has 
actually occurred and then the error can be pinpointed as 
having occurel in a particular type of field in a particular 
block* If only one checksum was found to be mismatched then 
that one was assuned to be corrupted and was replaced without 
indicating any error. This extra effort in this relation can 
be justified on the ground that the relation has numeric 
fields of total length 35 consecutive bytes and unless the 
exact error location is pin pointed, it becomes a very labo- 
rious process to try to locate it. 

This brings our discussion of the second phase of data 
validation in our data base project to an end. 

3-4. VALIDATION AFTER UPDATE 

In the third phase, namely that during the storage of the 
data after manipulation, the requirements for validation are 
generally the sane as in the first stage, as discussed earlier. 
The data may be subjected to primary edit. Next comes primary 
key validation. This assumes greater significance in that a 
constituent of the primary key could have been operated on, 
may be to correct an initial mistake, giving rise to the 
possibility of pr imar y key duplication. Also the plausibility 
and limit checks need to be done again as an altered data item 
may violate these constraints. Similarly the interfield 
relationship checks must also be made. If some of the Y/N 
type ■•£ fields have been replaced these need to be converted 
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again. Finally the new checksums must "be computed to replace 
the previous values. As is obviously true, the routines de- 
veloped to serve in the data base building phase suffice in 
this phase also, except when domains are deleted or added or 
domain types changed or interchanged. This, of course, changes 
the structure of the relation and of the whole data base as 
such and is not the topic of discussion here, 

3-5. VALIDATION DURING REPORT GENERATION 

In the last phase of our work, namely during the phase 
of report generation, the validation requirements are similar 
t; the second phase of data retrieval, for data must first 
be retrieved before report generation can be attempted. After 
the validation during the retrieval of the data, the following 
steps must be followed. The l/N type of domains are decoded 
to their proper values by the mECO routine. Next the check- 
sums are to be removed and packing of the data affected if 
necessary. Finally the Personnel Number must be relieved of 
the extra digit added to it during the coding process. After 

this the data is presented for output. 

This completes the discussion of the data validation 

requirements and the routines utilised to achieve these for 
the data base project. 



4. SOME DETAILS OP THE DATA VALIDATION ROUTINES 


4-1. INTRODUCTION 

This chapter describes the various algorithms developed 
for 'the actual validation of the data. The routines described 
here arc mentioned in their particular places of usage in the 
previous chapter and the detailed listing of the program which 
contains these routines and uses them is appended at the end 
of this write up* Since the detailed listing is given, only 
a few of the algorithms will be described in a step by step 
manner, the rest of the algorithms would not be specified in 
any great detail. 

Some general observations are appropriate here. The TDC- 
316 on which the system was implemented had 8 registers in all, 
being numbered from 0 to 7. Of these the first two, namely, 

0 and 1 are the location counter and stack pointer registers 
respectively, so these were not used for other purposes. The 
other registers were named R2 to R7 respectively and were 
widely used. Of these R2 was specifically used in subroutine 

calls, though it was also used otherwise. The buffer area 
BF3 was generally used as the common. input /output area for the 
main routine as well as in nearly all subroutines. 

4-2. GENERAL ROUTINE DE SCRIPTION 

We will first describe the general routine that is used 
for Initially validating the data and putting it in the data 
base. It vas developed in a manner suitable for our data 
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base and at present cators for the twelve relations built 
up but may bo extended, to accomodate any further relations 
developed later, with ease# There is, of course, no general 
algorithm ^s such# It involves first reading in the data 
about the relation to bo built up, namely the relation number, 
its present format, the number of tuples to be placed in this 
relation, the limiting values of the years anc. such other 
plausibility limits and finally the starting address, i.e., 
the cylinder, surface and sector numbers from which the rela- 
tion should be placed on the disk:# The format specifications 
nro chocked and coded properly by PEFORM as stated earlier, 
NOFRBC chocks whether the number of tuples to be placed is 
a positive, non-zero integer or not. Next the relation number 
is decoded and jump made to the particular section of the 
general routine dealing with that relation. These sections 
chock the various formats, primary keys, various interfield 
re la tionships and plausibility limits, calling various sub- 
routines in the process, compute and append checksums where 
appropriate (as discussed in Chapter 3) and then finally 
selects the proper area on the disk and places it there for 
the lRtcr purpose of data base BUILD function, being developed 
by a coworker, as stated earlier. 

4 - 3 - INSCRIPTION OF OTHER R OU TINES USB D IN THE FIRST PHAM 

How we will describe the subroutines used in the building 
phase of the data base. The routines would be. described in the 
order in which they appear in the listing of the progremme. 
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Subroutines P33FOBM : This routine makes use of two buffers, 
a one word buffer called FMT1 as temporary storage for manipu- 
lation and assembly of each of the domain formats and another 
larger buffer PMT where each domain format is placed in succe- 
ssive word locations. 

Algorithm *. The format card is read in and the data stored 
digi twice as an array represented here by F(l). 

Step 1: Sot F 0 , I *■*— 1, K — 80. 

Step 2; Compare F(l) to ’blank’. If equal go to Step 8c 

Step 3: Compare F(l) with 1,2,3 and 4 successively and 

place octal ‘O’, ’ 20 * , ‘40’ and ’60’ respectively 
for a match with these in the upper byte of FMT1. 
If no match is found, print error message and go 


out. 

Step 4: Convert F(I+l) and F(l+2) considering them as the 
1st and 2nd digits of a decimal number and store 


the binary result in the lower byte of FMT1. 


Step 5*. FMT(N+1 )■«*■" FMT1. 

Step 6: K*«—K - 3, If K ^ 3 go to Step 8. 

Step 7: I*- 1+3, N+l, go to Step 2. . 

Step 8s If F(3+3) 4 ’blank’, then read in next card, set 
1 and E* — 80 and go back to Step 2} else 


N— N+l, FMTU )-*— N, stop. 

gaiaaa&BS H0ERBQ -. This subroutine reads In the number of 
records to be placed In the relation, converts it to binary, 
confirns that it is a nonzero positive Integer and then reduoes 
its value by 1 end retains control to the main routine. Its 
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description is omitted. 

Subroutine PECHBg ; This subroutine reads in the tuple 
and checks it against the previously specified formats, stored 
in array FMT. The data is read into buffer BF3 which will be 
represented here by an array BF. 

Algorithm: 

Step 1: Check if number of fields (stored inFMT(l) is 
zero, if so indicate error and exit. 

Step 2: I-*-- 2, N-*-FMT(l), J-*-l 

Step 3: Transfer lower byte of FMT(l) to R4 and upper 
byte to R5. 

Step 4: Compare R4 with octal '0*. If equal go to 
Step 5. 

Compare R4 with octal '20'. If equal go to Step 7. 

Compare R4 with octad. *40'. If equal go to Step 9. 

Compare R4 with octal ’BO'* If equal go to Step 11 

Print error message and exit. 

Step 5: Check if BP(J) lies between octal *60* and '71* 
else indicate error and exit. 

Step 6: J-^t—J+l, R5 ** R5“l, 

If R5 > 0 go to Step 5 else go to Step 12. 

Step 7: Check if BF(J) lies between Octal ’O’ and *1* 
else indicate error and exit. 

Step 8: 3* J+l, R5-*“ &5 - 1. If R5 > 0 go to. Step 7 
else go to Step 12. 
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■-•tep 9. Check -if BF(j) lies between octal *101' and 

' 132 * or equal to ’blank 1 , else indicate error 
and exit. 

Step 10: J«~j + 1 , R 5 -*-R 5 - 1 . If R5 > 0, go to 
Step 9 else go to Step 12. 

Step 11: j + R5 # 

Step 12: I-*- 1+3, N-*~ N-l. If N> 0 go to Step 3 else stop. 

S ubroutine PNC ON : This calls two further subroutine PNCV 

and PNDC. The first one checks the alphabetic portion of the 
Personnel No. string and verifies whether it belongs to the 
allowed set or not (in the latter case indicates error and 
exits). The second subroutine computes the sum of the digits 
of the decimal portion and then the sum of the digits of the 

sum and so on until a single digit is obtained and this is 
appended to the end of the string. 

Subro utine YNCON : This subroutine takes as input a buffer 
area of one byte called YNBF, checks to find whether the contents 
are the equivalent of ASCII ’Y* or >N’, otherwise indicating 
error end exiting, thee finally substitutes a string of all l’s 
for *Y’ and all ‘0’s for ’N T in YNBF. 

Subroutine YlillM : This subroutine utilises three buffer 
areas of size one word each, YRUIi to contain the upper limit 
of the year value, YRIli to contain the lower limit of the 
year value and Y3U3F to contain the actual year value whose check 
must be made. Algorithm is again pretty simple consisting of 
checking YLEF against YR.TJ1 first and then against YRI&, either 
value being contravened indicated by error message and exit. 
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Subroutine ARSLC T : This subroutine selects the area on the 
disk at which iiie next tuple will be placed. The starting add- 
ress of the relation is, given initially as input in the form of 
cyliner, surface and sector numbers. Next, whenever a tuple 
is placed on the disk, it increments the sector number and 
checks whether it has exceeded ten or not. If it has exceeded 
10, it is replaced by 1 and the surface value is incremented by 
1. In that case, the surface value is next checked*to find 
out if it has exceeded 9. If so, the value in the cylinder 
field is incremented by 1 and the surface and sector numbers 
are replaced by 0 and 1 respectively. 

Subroutines for Disk I/O: These consist of three parts, 
namely set, read and write, of which only two, set and write 
were useful for our purpose in this section. These routines 
were developed by a coworker and so would not be discussed here. 

Subroutine COMCHE: This routine checks the command-region 
value for validity of that domain. If is a very simple routxne 

which takes the value of the domain from a buffer called C0MEF1 
and compares it with a fixed set of values, all of which unmat- 
ched gives rise to an error message and exit. 

Subroutine PECHEE: This subroutine validates the primary 
key for duplication and hence is a very important routine for 
our work. It uses three one-word buffers called PEN, PEI and 
PEB respectively. Of these, PEN is used to contain the number 
of primary keys stored till then in the primary key buffer 
whose starting address is placed in PEB. PEL contains the 
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length of the primary key of the tuples of the relation being 
presently stored. The array E(I) is used here to represent the 
primary key buffer and BE is used to represent the input buffer. 
Algorithm 

Step Is Set N-*-PKN, I-*- 1 

Step 2: Check if N is zero, then go to Step 7 
Step 3: Set J*«-PKI, E>*- 1 

Step 4; Compare BE(K) with E(l). If unequal go to Step 6. 
Step 5: K-*-K+l, I-*- 1 + 1, - 1. If J> 0, go to 

Step 4, else print error message and wait for 
restart. On restart go to Step 1* 

Step 6: K^- K + J, I*- 1 + J, - 1. If U> 0, go to 

Step 3. 

Step 7: Set J*- PEL, K*~l 

Step 8: F(I) BE (K ) , I-*~I + 1, + 1, J — J - 1. 

If J> 0, go to Step 8. 

Step 9s PEK -<t— PO + 1, 

Stop. 

Subroutine C0MC0D : This subroutine computes the digitwise 
checksums of the date domains and the other numeric domains 
separately as well as their sum and append these to the end of 
the tuple in the relation COMM. One-word buffers CMBE2 and 
CMBP3 are used to indicate the positions in the tuple from 
which the inp*t is to be taken and where the checksums are to 

be placed respectively. 
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Subroutine PQLCHK: This subroutine simply checks the 
grades in the relation PQTJAL for validity. The number of 
allowed grades is a small set and it compares the input in 
the buffer PQ1BP with these. A failure to match any of these 
gives an error message and sets a flag PQP which may be subse- 
quently used in the main routine to deteimine whether to insert 
the tuple or not. 

Subrou tine ABMCON : This subroutine converts the input 
from Corps domain in buffer ARMBFl from two byte ASCII to one 
byte binary and is of very elementary nature. 

Subroutine PLCQN i In this subroutine, we first check for 
plausibility of the level of exam passed. Next we calculate 
the positionwise checksum of the numeric domains and append it 
to the end of the tuple. At the same time the bytes of the 
tuple are transferred from the input buffer B3?3 to the foreign 
language buffer PLBP. 

Subroutine M55DCQD : This is one of the larger subroutines 
where, as stated earlier (in Chapter 3), we compute the sum 
of each individual type of domains P, M,Y and V, appending 
these to the end of the tuple, while at the same time the 
digitwise checksums of the blocks S,H,A,P and E are calculated 
and appended to the end of each block respectively. Two one- 
word buffers TEMP and TEMPI are used for intermediate or 
temporary storage in the process. Other buffers used are one- 
word buffers P,M,Y and V named after the domains respectively. 
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Subroutine INCVAL t This is again a very simple subroutine 
that validates the Ins titute-of -Commissioning domain. The 
values in this domain can again he from a fixed set of alpha- 
betic character strings end these are ma.tched with the present 
domain value character by character, any discrepancy giving 
rise to an error message. 

Subroutine QMiflOD ; This subr out in e c alculat es boththe 
positionwise and the digitwise checksums of the numeric fields 
in the relation QUAD and appends these at the end of tuple in 
that order respectively. It also transfers the input string 
from buffer BE3 to buffer QUDBF to help in writing on the disk. 
It uses the address of the input string given in the buffer 
Q1BF and utilises two one-word buffers Q1T0T and Q1T0T1 for 
calculating the checksums. 

This completes our discussion of the routines used in 
the first phase. 

4 - 4 , DESCRIPTION OF TBS OTHER ROUTINES 

These routines were developed to decode or check whatever 
data were coded or checksummed in the first phase. These rou- 
tines are to be utilised in the data retrieval and related 
phases by the person developing that part of the DBMS and so 
no general routine with a calling sequence for these was 
developed* 
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Subroutine QALVAL : This subroutine is used to recompute 
the position-wise and di&itwise checksums of the numeric domains 
in the relation QUAl and compare then with the previously- 
computed values stored at the end of the tuple. In the case 
that one of the checksums only mismatches, that is assumed to 
he in error and is replaced by the new value without indicating 
error. But if both the checksums mismatch then some of the 
numeric domains may be in error and this is indicated by an 
error message with a print out of the offending tuple. 

Subroutine FLEEC: This subroutine recomputes the position 
wise checksum of the numeric domains in the relation LAK&F and 
compecres it with the previously calculated and stored value, 
any discrepancy giving rise to an error message. 

Subroutine YNTfBGO t This subroutine checks the contents of 
a buffer TUBUT 1 for the number of l’s present and converts it 
accordingly to *T« or *H*. A is a one-byte buffer which is 
used to make the comparisons and it has only its first bit 
position a 1 and the rest Os. Let us assume that the binary 
string is present in array BF. 

Algorithm 

Step 1: I-*— 8, Z~*~ 0 

Step 2: Compare BF(l) with 1. If equal, then 3 J + 1 

Step 3: I*- 1 - 1. If I > 0, go to Step 2. 

Step 4: If J> 4, then HTBF = * else IHEF = 'H*. 


Stop. 
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Subroutine OOMEBG i This subroutine computes the digitwise 
sum of the date domains and of the other numeric domains in 
the relation COMM separately as well as computing the sum of 
the two. These are then compared with the previously computed 
and stored values. Any single mismatch is assumed to "be in 
the checksums themselves and these are replaced. In all other 
cases an error message followed by a printout of the tuple 
occurs. 

Subroutine MEDVAL : This subroutine recomputes the check- 
sums calculated by the MEDCOD routine and compares then with the 
previous values. It first goes on a block by block basis, 
comparing the block checksum on reaching the end of each block. 
If any discrepancy occurs, the corresponding block error flag 
is set. When it reaches the end of the last block, it checks 
whether any of the flags are set*, otherwise it just replaces 
the domain checksums by the newly computed values and exits. 

But if any flag is set, it s tarts checking the domain checksums. 
If none of them mismatch, it replaces the block checksums by 
the new value and exits. When both some block and domain type 
checksums are found to be mismatched, it prints the offending 
tuple after a message indicating -the exact error location in 
terms of the block and domain. 
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Subroutine BINASC : This subroutine converts a one byte 
binary number to a 3—digit decimal number is utilised with 
many of the validate routines of this section s in ce otherwise 
the tuples printed will contain many odd characters in the 
checksum fields which are in binary form. 

This completes our discussion of the routines used to 
validate the data in our data base. 



5. CONCLUSION 


As stated early in this work, not much work has been done 
.i.n the field of data validation in a data base. So this field 
needs to be investigated further and presently sone interest 
seems to have been created in it. 

It was also stated in the first chapter that our aim was 
to implement a relational model of data base management system 
to investigate its claims of superiority to other models. This 
present work does not involve much of the relational model 
except where the structure was built up, i.e., in the work of 
normalizing the data base. It was found that the data valida- 
tion requirements were not much different from what they would 
have been in the other models. But one thing was found out, 
that this model helped in determining the exact requirements and 
in accessing the portions of the data required to be validated 
very easily, due to the flat file sort of structure of the 
relations. This simplicity was very much evident in comparison 
with the chain- link determination in the network model and the 
tree traversals that would have been required in the hierar- 
chical approach. The validation of primary keys and other 
similar single domains was specially made easier by this 
structure. 
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{BEGINNING 
{ THE MAIN 
{ THE DISK 
{ 

I DEFINE CONSTANT'S 
{ 

» *5 0000 

R2*#2 

R3s*3 

R4*84 

R5=%5 

R 6*5*6 

R7s%7 


OF THE GENERAL ROUTINE 

^° U IJNE USED TO VALIDATE THE DATA AT INPUT AND PLACE IT ON 
IN THE FINAL FORM OF THE 12 RELATIONS 

AND REGISTERS 


N 2*2 
N3* 3 
N4*4 


N5b5 

M Q*1777 36 
RESET 

INIT N 2 * BF 1 {INITIALIZE THE READER 
I NIT N3.BF2 { INITIALIZE THE PRINTER 
INIT N4.BF7. I INITIALIZE THE TELETYPE 
INI T N 5* BF 14 I INITIALIZE THE KEYBOARD 
JMS R4,SET 

TSR #40000 »PKB { STARTING ADDRESS OF THE PRIMARY KEY BUFFER 
PL21! SWRITE N4, PBF5 
L43» WAITR N4.L43 
SREAD N5 ,PBF1 
FLU WAITR N5.PL1 

BTSR PBF1+6, PBF2+35 
BTSR PBF1+7.PBF2+36 
SWRITE N3, PBF2 
PL665 WAITR N3,PL66 
JMS R2,N0FREC 
JMS R2,PEFQRM 
STOP 

SREAD N2.FRBF 
PL231. HAITR N2.PL23 

I FOLLOWING SECTION DETERMINES THE DSTARTING DISK ADDRESS 
SREAD N2»DASBF 
DLlt WAITR N2.DU - 
CLR R2 
TSR #12, MO 

BTSR DASBF*6,R2 ' . . 

SUB #60. R2 
MPY R2,R2 : 

TSR MQ»R2 ’ 

CLR R3 
TSR #12, MO,. 

BTSR DASBF*7,R3 
SUB #60, R3 
MPY R3»R3 
ADD MQ,R2 
CLR R3 J 
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6RZS PL3 
SUB #4,R3 
BRZC PL2 
J KP PL 4 

P6F 2t WORD 33,0,33 

BCI * BUILDING RELATION NO, X 

BYTE 0,0,15,12 

EVEN 

DA SB F ! WORD $,0*6 
* 8 • +6 

BF14! WORD 1 
PBF11S WORD 35,0,35 

BCI X RELATION DOES NOT EXIST X 

BYTE 15*12 

EVEN 

j JUMP TO THE DIFFERENT SECTIONS FOR THE DIFFERENT RELATIONS, 

J The jumps are ordered in the reverse order to The no', of the relations. 

I SC FOR JUMPS TO ANY NEW SECTIONS THESE SHOULD BE ADDED TO THE TOP 
PL 2! JMP PL3(R3> 

JKP PL 20 
JMP PL 17 
JMF PL 16 
JMP PL 15 
JMP PL 14 
JMP PL 13 
J HP PL 12 
JMP PU1 
JMP PL 10 
JMP PL? 

JMP PL 6 
JMP PL 5 

PBF1* WORD 3,0,3 

S +4 

FREF* WORD 120,0,120 
, *» *1 20 

PL 4 S SWRITE N4, PBF11 
PL22S WAITR N4,PL22 
STOP 

JMP PL 21 

UR* WORD 111,0,111 
BYTE 15,12 

BCI XWHAT IS WORDLENGTH OF RECORD* 

BCI X( AS TWO D 16 If DECIMAL INTEGER ON K80)X 
BYTE 15,12 
EVEN 

RL* WORD 3,0,3 

ss +4 

DHBF* WORD 0 , 

,*,♦400 

PDRBFf WORD 0 
PBfSf WORD 50,0,50 

!ct fi XGlVE i REL‘» NO, <AS TWO-DIGIT INTEGER)* 

BYTE 15,12 
. EVEN . 

NRPSl WORD 0 . 



92 


BTSR 

DASBF nO 

SUB 

#60, R3 

ADD 

R3,R2 

TSR 

R2 ,C YU 

CUR 

R2 

BTSR 

DASBF +11 

SUB 

#60, R2 

TSR 

#12, MQ 

MPY 

R2,R2 

TSR 

MQ ,R2 

TSR 

#12, MQ 

CUR 

R3 

BTSR 

DASBF *12 

SUB 

#60, R3 

MPY 

R3,R3 

ADD 

MQ,R2 

CUR 

R3 

BTSR 

DASBF+13 

SUB 

#60, R3 

ADC 

R3 , R2 

TSR 

R2,DIS 

SWRITE N4.KR 


L3S WA1TR M,U3 
SREAD N5,RU 
U6I WAITR N5,U16 
CUR R2 
CUR R3 
8TSR RU*6,R2 
SUB #6Q,R2 
TSR #12* MG 
MPY R2»R2 
TSR MQ,R2 
BTSR RU+7,R3 
SUB #60, R3 
ADC R3 »R2 
TSR #200, MQ 
CUR R3 
D XV R2,R3 
TSR MQiNRPS 
TSR #DRBF,PDf?BF 

TSR NRPS»NRPS1 r 

STOP . J 

} FOUUCWING SECTION DETERMINES THE NO, OF ThE REUATjG FOR JUMP TO THAT SECTIONS 
TSR #60, R3 I THIS VAUU6 TO BE INCREMENTED BY 4 FOR EACH NEW RELATION » 
I ADDED tO THE DATABASE i‘ 

CUR R2 
CUR R4 

BTSR PBFl«6iR2 
SUB #60, R2 
TSR #12, MS 
MPY R2,R2 
TSR MQ,R2. . 

BTSR PBF1*7,R4 
SUB #60, R4 • 

, ADD R4,R2 

• FL 21 DEC R2 . ... 
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JKS R2 iYNCON 
BTSR YNBF# NAMEBF+66 
8TSR 8F3+74* YNBF 
JKS R2.YNC0N 
BTSR Y NB F » NA ME BF +6 7 
TSR #5,R2 

PU2«{ BTSR BF3+74C R2 ), NAME 8F +67( R2 ) 

DEC R2 
BRZC PL26 
9 TSR BF3+102,YNBF 
JKS R2#YNC0N 
BTSR YNBFi NAHEBF+75 
BTSR BF3+103#YNBF 
JHS R2'YNC0N 
BTSR YNBF,NAKEBF+76 
BTSR BF3 *1 04 *YNBF 
JMS R2 iYNCON 
BTSR YNBF, NAMEBF+77 
BTSR BF3+105#YNBF 
4MS R2 #YNCON 
BTSR YNBFiNANEBF+lQQ 
BTSR BF3+106 #YNBF 
JMS R2 iYNCON 
BTSR YNBFi NAKEBF+101 
BTSR BF3+107 »YNBF 
JMS R2*YNC0N 
BTSR YNBF,NAMEBF+102 
BTSR BF3+U0.YK8F 
JMS R2 iYNCON 
BTSR YNBFiNAHEBF+103 
BTSR BF3+111 iYNBF 
JtfS R2 iYNCQN 
BTSR YKBF* NAMEBF +104 
BTSR 8F3*112#NAMEBF+1Q5 
BTSR B F3 ♦! 13 |N AMS8 F* 10 6 
T SR PD RB Fi R2 
T SR #i 07 *R 4 
TSR #N AM EB F ♦ R3 
IZli BTSR ( R3 >* #( R2 )♦ 

DEC R4 
BRZC L31 . 

TSR R2,PDRBF 
DEC NR PS 
BRZC t 32 
JKS R2»DWR 
12 2 t DEC C 

BRSC P160 
CMP #0 #NRPS 
BRZS 133 
JMS R2»DWR 
L3 3 1 TSR NRPS1# NR PS 
J MP PL 21 

PL6C1 JMP. PL 40 , 

NAMEBPI WORD 0 . 

I BEG INNlN.Q^OF SECTION TOR RELATION * 3* 



fcRPSl: 4QRD 0 

1 BEGINNING OF SECTION FOR RELATION » 
PL 5 5 TSP #BF3 *6 *PNBF 
TSR #ARHBF,PNBtF 
CLR PKN 
TSR #U*PKL 
PL5H JMS R2#PECHEK 
JMS R2 # PKCHEK 
JHS R2,PNC0N 
BTSR BF3+15» ARNBF1 
BTSR BF3n6» ARH8F1+1 
JHS R2 iARMCON 
BTSR ARMBFli ARHBF+iO 
BTSR SF3+17# ARHSF+U 
BTSR 8F3+20,YNBF 
JMS R2 # YNCQN 
BTSR YNBF, ARMBF+12 
TSR PDRBF* R2 
TSR #ARMBF»R3 
TSR #15*R4 

L 26 : BTSR (R3 )♦» <R2 ) + 

EEC R4 
BRZC L 26 
TSR R2,PDRBF 
DEC NR PS 
BR2C U27 
JMS R2*DWR 
L27t DEC C 

BRSC PL51 
ChP #0 »NRPS 
BRZS 130 
JM.S R2»DWR 
L3C« TSR NRPS1* NR PS 
JKP PL 21 

j BEGINNING OF SECTION FQR RELATION » 
PL 6* TSR #BF3+6,PNBF 
TSR #NAMEBF,PNBUF 
TSR FRBF+6,YRUL 
TSR FR»F*10# YRLL 
CLR PKN . 

TSR #7 iPKL 
PL4G* JMS R2,PECHEK 
JMS R2#PKCHEK 
JMS R2 tPNCON 
TSR #5 Q * R2 . , 

PL24* BTSR 8F3*14(R2 }# NAMEBF *7 (R2) 
DEC R2 
BRZC PL24 
BTSR BF3+6B.Y18F 
BTSR BF3*66# YL BP ♦! 

JMS R2.YRi.IM 

^ 2 

PL2SI BTSR BF3464<R2>#NAMEBF+57(R2) 
DEC R2 . 

BRZC Pl.25 
BTSR BP3*73»YNBF 


L2!s: DEC ■ C 

6KSC PL41 
C*P #0*NiRpS 
8RZS L36 
JMS R2.DWR 
US e s TSR NR PS 1* NR PS 
J HP PL 21 

J EEC- INNING OF SECTION FOR RELATION » 4» 


FLIP* 

TSR 

#B F3 +6 »P NBF 


TSR 

#QULBF iPNBUF 


CLR 

PKN 


TSR 

#1 X. PK L 

FL42S 

JMS 

R2 »PECHEK 


J NS 

R2,PKCHEK 


JMS 

R2 iPNCON 


TSR 

FRBF +6,YRUL 

i 

TSR 

FRBF+10,YRLL 


TSR 

BF3+24,YLBF 


JMS 

R2,YRLIM 


TSR 

#BF3+15,GLBF 


JI'S 

«2,QALCQD 


TSR 

PDRBFi R2 


TSR 

#2 4.R4 


TSR 

#GULBF»R3 

LS 78 

aTsR 

i ( R3 )+ »< R2 )+ 


DEC 

R4 


BRZC L37 
T SR R2 #PDR0F 
DEC NRPS 
BRZC L46 
JMS R2#DWR 
L4e: DEC C 

8R8C PL42 
C^P #0,NRPS 
8RZS L47 
JtfS R2 »D WR 
L47: TSR NRPS1» NRPS 
JfcP PU 21 

l 

i beginning of section for RELATION « 5 * 
PLUS TSR #8 F3 *6 »P NB F 
TSR #LIBFiPNBUF 
CLR PKN 
TSR #lliPKL 
PL43! JMS R2 »PECHEK 
JMS R2^PKCHBK 
4 NS R2»PNC0N, 

8TSR BF3+20.YNBF 
JNS R2i.YNC0N , 

BTSR YNBF* LtBF+13 
BTSR BF3+15,LIBFnO 
BTSR BF3+l$*LtBF *ii 
8TSR BF3fl7»tIBF*12 
TSR PPRBFt R2 
TSR #13* R4 



PL 7S TSR 

#BF3+6 #PNBF 

TSR 

#combf,pnbuf 

CL^ 

PKN 

Ts* 

#7 ,PKU 

PL41: JMS 

R2 »PECHEK 

JMS 

R2,PKCHEK 

JKS 

R2»PNCCN 

T SR 

FRBF+6,YRUL 

TSR 

frbf+iq.yru. 

ETSR 

BF3+i5,YUBF 

FTSR 

BF3+16 iYLBF+I 

J MS 

R2 »YRL IM 

TSR 

FRBF +12* YRD|» ' 

TSR 

FRBF+14»YRU 

ETSR 

BF3+23 »YUBF 

ETSR 

BF3+24,YlBFn 

JPS 

R2iYRL IH 

TSR 

FRBF+16,YRUU 

TSR 

FRBF +2 0# YRLU 

ETSR 

BF3+31,YUBF 

ETSR 

6F3+32#YLBF+i 

jhs 

R2,YRLIM 

TSR 

FR8F^22»YRUL 

TSR 

FR 6F f2 4# YR IL 

ETSR 

BF3*40, YtBF 

ETSR 

BF3+41# YIBF +1 

JKS 

R2#YRUM 

TSR 

FRBF +26# YRUL 

TSR 

FR9FT3 0.YRU 

BTSR 

BF3+44* YIBF 

ETSR 

BF3+45* YUBF +1 

J MS 

R2»YRIJM 

TSR 

#CQMBF *63# CMBF3 

TSR 

#BF3*15» CMBF2 

JMS 

R2* COM COD 

TSR 

#BF3+50*C*BUF 

JMS 

R2 # INCVAt 

TSR 

#BF3+i5# R2 

TSR 

#CCMBF*iO#R3 

TSR 

#45* R4 

PL27: BTSR 

( R2 )♦ »{R3 >♦ 

DEC 

R4 

BRZC 

PU27 . 

BTSR 

COMBF *46»YNBF 

JKS . 

R2 iYNCQN 

BTSR 

YNBF* CQM6F+ 46 

TSR 

PDRBF,R2 

TSR 

#100 *R4 

TSR 

#C0MBF*R3 

1341 BTSR 

( R3 )♦ »( R2 )* 

DEC 

R4 

BRZC 

1.34 

TSR 

R2#PDRBF * 

DEC 

NR PS 

BRZC 

135 

JHS 

R2#DWR 
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BTSP 

( R3 >4- »< R2 

dec 

R4 

BRZC 

L50 

T SR 

R2 ,P DR 8F 

DEC 

NRPS 

BRZC 

LSI 

JKS 

R2,DWR 

DEC 

C 

BRSC 

PL43 

CHP 

#0 ,N RPS 

RRZS 

L52 

JNS 

R2.DNR 

TSR 

NR PS 1, NRPS 

JMP 

PL 21 

WORD 

0 


• = » *1 2 

i >3£G INN I KG OF SECTION FOR RELATION ♦ 6* 
FU2? T SR #BF3+6,PNBF 
TSR #FLBF l PNBgF 
CLR PKN 
TSR #u,pkl 
Pl4<i JMS R2,PECHEK 
JNS R2,PKCHEK 
JMS R2,PNCON 
TSR FRBFt6»YRUL 
TSR FRBF+lOtYRU 
TSR BF3+ 20»YLBF 
4MS R2,YRLIM 
J^S R2,FLCQN 
TSR PDRBF* R2 
TSR #16, R4 
TSR #FLBF,R3 
L53: BTSR <R3>+,<R2>+ 

DEC R4 
BR2C L53 
TSR R2 fPDRBF 
DEC NRPS 
BR2C 1 54 
JKS R2 ,'DWR 
15 41 DEC C 

BRSC PIAA, 

CKP #0 ,NRPS 
feRZS L55 
JMS R2 ,DlmR 
L55: TSR NRPS1, NRPS 
JMP PU21 

i BEG IN N 2 M3 OF SECTION FOR RELATION » 7* 
PL131 T$R #BF3+6,PNBF 
TSR #P0BF,PNSLF 
TSR FR0F *6»YRUL 
TSR FRBF+1 0, YRLL 
CLR PKN 
TSR #11, PKL 
PLA5* iJNS R2 iPECHEK 
JM$ . R2,PKC.HEK 
J-MS R2,PNC ON 
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tsr 

3F 3+ 20,YLBF 

JMS 

R2,YRLIM 

BTSR 

BF3+17* PGLB 

JHS 

R2 #PGLCHK 

TSR 

#BF3+15,R2 

TSR 

#P QB F+10 «R 3 

TSR 

#5»R4 

: BTSR 

( R2 )♦ , ( R3 >+ 

DEC 

R4 

L'RZC 

PL30 

TSR 

PD RBF.R2 

TSR 

#lfit R4 

TSR 

#PQBFj, R3 

S E TSR 

(B3)*,(R2>* 

DEC 

R4 

epzc 

1 56 

TSR 

R2 iPDRBF 

DEC 

NR PS 

BRZC 

L57 

JMS 

R2,DwR 


L57J DSC C 

B FS C P IA 5 
CMP #Q,NRP5 
BR2S 160 
JMS R2,BNR 
1.6 C S TSR NRPS1.NRPS 
JHP PD 21 

J beginning of section for relation * at 

PU4: TSR #8F3*6 #PN8F 
TSR' #NCBF»PNBUF 
CUR PKN 
TSR #7»PKL 

FU6i JMS R2#PECHEK 
JMS R2,PKCHEK 
JMS R2#PNC0N 
JMS R2, MED COD 
TSR PDRBF,R2 
TSR #64»R4 
TSR #MCBF,R3 
Lfil* BTSR ( R3 )+ »( R2 )♦ 

DEC R4 
BR2C L61 
TSR R2 iPDRBF 
DEC NR PS 
BRZC L62 
JMS R2 »B WR 
L62* DEC C 

BRSC PL4 6 
CMP #0,NRPS 
BRZS 163 
JMS R2 #DWR 
L6 3l TSR NRPSl,NRPS 
JMP PU 21 

l BEGINNING of SECTION FOR RELATION » 91 

PL15: TSR #BF3*6*PNBF 
TSR #UNT.BFfPNBUF 
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CUR PKN 
TSR #7,PKL 

PM 7 i JKS R2#PECHEK 
Jt'.S R2,PKChEK 
JMS «2#PNC0N 
T SR #BF3+1S. R2 
TSR #UNTBF+10,R3 
TSR #7 »R4 

PU31* BTSR (R2 )♦ #(R3 )♦ 

DSC R4 
BRZC PU31 
BTSR BF3+24. CCMBFl 
JHS R2.C0MCHK 
BTSR 8F3+24* UKTBF+17 
TSR FRBF+6.YRUL 
T3P FRBF+10.YRUU 
BTSR BF3+23.YLBF 
BTSR 6F3+26* YLBF +1 
JHS R2.YRLIM 
TSR #8F3+25. R2 
TSR #UNTBF +20* R3 
TSR #7,R4 

PU32* BTSR (R2 )+ »<R3 >+ 

DEC R4 
BRZC PL32 
BTSR BF3+34»YRBF 
J*S R2 # Y NC ON 
8 TSR YNBF# UNTBF+27 
BTSR BF3+35* YNBF 
JMS R2.YNC0N 
BTSR YNBF,UNTBF+30 
TSR FRBF+12* YRUL 
TSR FRBFn4,YRLL 
BTSR 8F3+37.YLBF 
BTSR 8F3+40# YLBF +1 
JMS R2.YRLIM 
TSR #8F3+3 6,R2 
TSR #UNTBF+31»R3 
TSR #10. P4 

PL33* BTSR ( R2 )+ #< R3 >+ 

DEC P4 
BRZC PL33 
BCMP BF3+34iBF3+45 
BRSS P 154 
TSR FRBF+16* YRUL 
TSR FB0FtaO#yRLU 
TSR BF3*46,YUBF 
JMS R2#YRLI« 

TSR #BF3*4S.R2 
TSR #UfwTBF+4i*R3 
TSR #<►» R4 

PL34« BTSR <R2 )♦ *<R3 )+ 
DEC R4 
BRZC PU34. 

BTSR. BF3^4#YNBF 
' JMS R2,YNC0N 
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BTSR YNBF, UN TBF+ 47 
PTSR BF3+55, YNEF 
J*S R2,YNC0N 
3TSR YNBF# UNTBF+50 
TSR PDRBF, R2 
TSS #52, R4 
TSS #UKTBF.R3 
L7j. BTSR (R3)+,(R2) + 

DEC R4 
BR2C L 70 
TSR R2,PDRBF 
Dec NR PS 
BRZC U71 
JMS R2,DWR 
171: DEC C 

BRSC P 1,61 
CHP #Q,NRPS 
BRZS L72 
JMS R2,DNR 
172: TSR NR PS 1 * NR PS 
JHP PL21 
RU1* JWP PL 47 
P L54: SWRITE N4,RNERR 
PISS: WAITR M,PL55 
STCP 

J KP PL 47 

Rf- 6R Rt NORC 47,0,47 

BC I % FRESENT**RANK IS LESS THAN SUBS-RANK % 
BYTE 15,12 

EVEN 

U-TBF : WORD 0 

. *,+100 

J BEGINNING OF SECTION FOR RELATION »10» 
PL3e: TSR #BF3+6,PNBF 
TSR #M INBF ,PNBUF 
CLR PKN 
TSR #11, PKL 
PL52: JMS R2,PECHEK 
JMS R2,PKCHEK 
OPS R2,PNC0N 
BTSR BF3 +15, MI NBF+10 
BTSR BF3*16» MlNBF+ll 
BTSR BF3+17, HI NBF+12 
TSR PDRBF»P2 
TSR #13, R4 
TSR #M INBF ,R3 
L73: BTSR <R3)+»(R2)+ 

DEC R4 
BRZC L73 
TSR R2,PDRBF 
DEC NRPS 
BRZC L?4 : 

JMS R2'DWR 
1.7 4 1 DEC C 

BRSC PU2 

CMP #0 ,NRPS 
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BRZS 

L 75 


JFS 

R2.DWR 

u 

TSR 

NRPSl.NRPS 


JMP 

PL 2 % 

FINEFi 

WORD 

0 


.*.♦12 

i BEGINNING CF SECTION FOR RELATION * 11 * 

FLi7 ! CLR 
TSR 

Ft it 7 1 JhS 
JKS 
TSR 
TSR 
UK'S 
TSR 
TSR 
JHS 
TSR 
TSR 
TSR 
JfcS 
TSR 
TSR 

BTSR BF3+65iYLBF 
8 TSR BF3+66# YLBF+1 
JMS R2,YRLIM 
TSR #8F3+24,R2 
TSR #REMBF+2 0*R3 
TSR #50 * R4 



BTSR 

(R2 )♦# < R3 )♦ 


DEC 

R4 


3RZC 

PL35 


TSR 

PDR8F.R2 


TSR 

#6 6* R4 


TSR 

#REMBF*R3 

L76J 

BTSR 

(R3)+,(R2) + 


DEC . 

R4 


BRZC 

L76 


TSR 

R2.PDRBF 


DEC 

NR PS 


BRZC 

L77 


JNS 

R2»DWR 

L77! 

DEC 

C 


BRSC 

PU 07 


CMP 

#0*NRPS 


BRZS 

Lioo 


%IMS 

R2.DWR 

LlQCi 

TSR 

NRPSi* NR PS 


JMP 

PL 21 

REN8F* 

WORD 

0 


.**♦74 

i BEGINNING OF SECTION FOR RELATION H2’ 
PL20* TSR #BF3**#PNBf 
TSR #DEOBF*FNBUF 
CUR .PKN 
TSR #lt» PKt 


PKN 

#7iPKL 

R2.PECHEK 

R2iPKCHEK 

#BF3 +6 „PNBF 

#REMBF *PNBUF 

R2.PNCCN 

#BF3+15» PNBF 

#REMBF +10* PNBUF 

R2.PNC0N 

FRBF+6.YRUL 

FRBF+10.YRU 

BF3+24.YLBF 

R 2 .YRLIN 

FRBF +1 2* YRUL 

FRBF+14.YRLL 
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FL5 3: 

J MS 

R2,PECHEK 


JMS 

R2,PKChEK 


J MS 

R2 ,P NO ON 


TSR 

FRBF+6,YRLL 


TSR 

FRBF+10.YRLL 


8 TSR 

8F3+17» YLEF 


3 TSR 

BF3+20.YL6F 


JMS 

R2»YRLIM 


BTSR 

3F3*21* COMBi 


JKS 

R2 iCOMCHK 


TSR 

#BF3 +15,R2 


TSR 

#DECBF*lQ,f?3 


TSR 

#5 »R4 

' PL36! 

BTSR 

( R2 )+ , ( R3 >♦ 


DFC 

R4 


BRZC 

PL36 


TSR 

PDRBF, R2 


TSR 

#16, R4 


TSR 

#DECBF »R3 

LlOll 

8TSR 

<R3>+,<R2)+ 


DEC 

R4 


BRZC 

L101 


TSR 

R2 cPDRBF 


DEC 

NRPS 


B R 'Ajf 

L102 


JMS 

R2,DWR 

UC2; 

DEC 

C 


8RSC 

PL53 


CMP 

#0 ,NRPS 


BRZS 

L103 


JMS 

R2»DWR 

Lit.) 3! 

TSR 

NRPSl,NRPS 


JMP 

PL 21 

BECBFi 

WORD 

G 


.*,+14 

HFli 

WORD 

7. 

3F2S 

WORD 

8. 

■ BF 7 ! 

WORD 

2 

BRAD DR 

: WORD 0 

EF3J 

WORD 

120,0,120 


, * » +1 20 

r; i s # 

WORD 

1 

CYLJ 

WORD 

55 . 

set 

WORD 

-200 


I 

} THE SUBROUTINES USED IN THE INPUT VALIDATIONS STAGE 
) 

f BEGINNING OF SUBROUTINE REFORM 
J 

REFORM i TSR R2*B 

TSR . #1 20 «BF3 
Lit SREAD N?,8F3 
L 29 WAZTR N2 ,L2 . 

TSR #120 »R«, 

TSR #BF3+6#R2 




T SR 

#F BF +6 0, R3 

L65S 

BTSR 

<R2)+,<r3>+ 


DEC 

R4 


8RZC 

L65 


SwSITE N3.FBF 

L<» 4 : 

waitr 

N3 |L 44 


TSR 

#120 »R2 


TSR 

#6 #R3 


CLR 

R6 


CLR 

R7 

14s 

CLR 

R5 


CLR 

R4 


BTSR 

BF3(R3)iR4 

LSI s 

BCMp 

blank, R4 


8RZS 

L24 


ADC 

#2,R6 


SUB 

#60, R4 

L5S 

SUB 

#1 ,R4 


3RZS 

L25 


AD0#2 

,R5 


CMP 

#10, R5 


BRZC 

L5 


SNR IT E N3.BF4 

L 7* 

NAITR 

N3,L7 


JMP, 

L4Q 

iZAi 

JMP 

L15 

L2SS 

JMP 

L6(R5) 

RF « 8 

WORD 

14 , , 0, 14 , 


SCI . 

^UNKNOWN FORMAT* 

AS 

WORD 

1 

c: 

WORD 

0 

6 i 

WORD 

. =. *4 

4,0,4 

AN K S 

WORD 

EVEN 

40 

MTls 

WORD 

0 

fmt t 

WORD 

0 


.=,+200 

C* 

WORD 

0 

FSFl 

WORD 

122., 0,122, 


BCI ft THE FORMAT OF FIELDS OF THIS RELATION IS % 
, +120 . 

EVEN 

L 6i BRN L10 
0RN Lll 
BRN LI 2 
BRN L13 

LI 01 BTSR # Of FMTi+1 
BRN 122 

Lilt BTSR #2Q, FMTi+1 
BRN L22 

LI 21 BTSR MO # FMTl*i 
BRN L22 

L13t BTSR #60 ,FMTl+i 

L22) BTSR 0F3+1 <R3) *Rf 
SUB #60»R4 
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T SR 
MPY 
TSR 

btsr 

sue 

ADD 
Ul7: ADD 

sue 
8 TSR 
ADC 
TSR 
TSR 
SUB 
BRSS 
JHP 

U14* BTSR 
EC Mp 
5RZS 
SREAD N2 #8F3 
L22S WA1TR N2 . L23 
TSR #6,R3 
TSR #8Q, ,R2 
JMP U4 

US: TSR R7,FMT+2<Rfi) 

A SR R6 
TSR R6.FNT 
TSR D.R2 . 

RTS R2 

; 

i ENE OF SUBROUTINE PgFQRM 
i 

i 

} 

I SUBROUTINE NCFREC 


i 


NOFREC « 

i TSR 

R2.D 


TSR 

#-3« R4 


&RE AD 

N2.B’ 

L41: 

W A I TR 

N2,U41 


TSR 

#4,R5 


TSR 

#8+6 »R2 


TSR 

#NRBF+52»R3 

U66: 

•a TSR 

{ R2 >♦ » < R3 )♦ 


DEC 

R5 . 


BRZC 

U66 


SNR ITE N3.NRBF 

167: 

WAITR 

! N3iU67 


CUR 

R2 

U45: 

TSR 

#12, MQ 


CUR 

R3 . .. 


8 TSR 

B+il(R4)*R3 


SUB 

#60*83 


ADD 

R3.R2 


MRY 

R2.R2 


TSR 

KQiRR 


ADD 

#i*R4 


#1 2. MQ 
R4 ,R4 
NQ »R4 

BF3+2 CR3) #R5 
#60. R5 
R5 »R 4 
#3 #R 3 
#3.R2 
R 4. FN Tl 
R4.R7 

FMTl ,FMT <R 6 ) 
R2.R4 
#3.R4 
Ul4 
L4 

BF3+85* #R4 
BUANK.R4 
L15 



BR2C IA5 
BTSR B+U,r3 
SUB #6 0, R3 
A DO R3 ,R 2 
TSR R2,c 
DEC C 
BRSC L42 
JMP L40 
L4 2! TSR D,R2 
RTS R2 

NRBF: WORD 50,0,50 

BCI % the no, of records to be placed is % 

i s .+4 

EVEN 

i 

S END OF MOFREC 

9 

9 

f 

I BEGINNING OF SUBROUTINE PECHEK 

; 

PECHEK: TSR R2* D 
TSR #2,R6 
TSR FHT* R2 
SUB #1 »R 2 
BRSS PEL 3 
TSR #2,MQ 
MPY R2,R7 
TSR FMT+2I R7 ) , BF3 
TSR FMT+2( R7 )# BF3+4 
PEL 1? SREAD N2 »BF3 
PELS! WAITR N2,PEL2 
TSR #6,R3 
PELU! CLR R4 

BTSR FNT+l (R6) »R4 
CLR R5 

BTSR FMf(R6),R5 
SUB #1 »R4 
BRSS PEL 4 
SUB #20, R4 
BRSS PELS 
SUB #20, R4 
BRSS PEL# 

SUB #20, R4 
BRSS PEL 7 
S WRITE N3, PERQR 
PEL10! WaITR N3 iPELIO 
ADC #2 ,R6 
ADD P5,R3 
BRN PELU 

PEL 3 1 SWRITE N4,PEERR 
PE LI 2! WAITR N4,PEL12 
4«P PEL36 
PELS! JMP PE 12 3 •' 

PEL6I 4 HP PEL30 
P6L7! 4HP PEL35 
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PEL At CLR R4 

b TS R B F3 (R 3) |R 4 
PE LI 5 * SUB #60, R4 
SPSS PEL 16 
SUB #12, R4 
BRSC PEL 16 
ADD #1 ,R3 
SUB #1,R5 
BRZS PEL 17 
BR<\ PEL4 

PE LI 6: SWRITE N3, FMERR 
PEL2 0: WAITR N3,PEL20 
BRK PEL22 
PE LI 7 S SUB #1 ,R 2 
BBSS PEL 22 
A DC #2 ,R 6 
JMP PEL11 
PEL22J TSR #2 ,R6 
JMP PE136 
PELS 3! CLR R4 

BTSR BF3<R3),R4 
FEL25! SU8 #1,R4 
BRSS PEL 27 
SUB #1,R4 
BRSC PEL 27 
ADD #1,R3 
SUB #1 »R5 
BRZS PEL 26 
BRN' PEL23 
PEL26* JMP PEL17 
PEL27: JMP PE LI 6 
PEL3CJ CLR R4 

BTSR 8F3 (R3) ,R4 
BCMP BLANK, R4 
BRZS PEL 37 
PEL3 2» SUB #1 01 »R4 
BRSS PEL33 
SUB #32, R4 
BRSC PEL 33 
PEL37J ADD #1,R3 
SUB #1 ,R5 
BRZS PEL34 
BRN PEL30 
PEL33* JMP PEL16 
PEL34f JMP PE Li 7 
PBL3 5S ADD R5,R3 
JMP PE LI 7 
PEL36I TSR D.R2 
R TS R2 

PERGRi WORD 42.0*42, 

BCI * FORMAT corrupted during transfer* 

PEERRl WORD 42. 0. 42 . 

BCI % NO OF FIELDS IN RELATION IS ZERO* 
FMERRl WORD 40,0.40 

BCI * FIELD NOT MATCHING WITH FORMAT* 

I ’• '■ '• ' ■ . 


J END OF SUBROUTINE PECHEK 
I 

J 

I SUBROUTINE PNCON 

f 

FNCCN5 TSR R2,D 
JMS R3,PNCV 
JNS R3»PNDC 
TSR D»R2 
R T$ R2 
PNBUF! WORD 0 
pNBFj WORD 0 
i 

i END OF PNCON 

i 

* 

I SUBROUTINE PNCV 


PNCV J 

TSR 

#2,R6 


TSR 

#CC,R5 

PNL4J 

TSR 

PNBF.R4 


TSR 

#2*R2 


TSR 

<R5) *t R7 

PNLSs 

BCMP 

(R4)+»{ 


BRZS 

NXT 


DEC 

R6 


BRZS 

NOMTCH 


BRN 

PNL4 

NXTS 

DEC 

R2 


BRZS 

PNL6 


BRN 

PNL5 

CD! 

WORD 

CDI iCD2 

CDi: 

BCI 

XI CX 

CD 2: 

BCI 

XSSX 


KOFTCHj SWRITE N4,PNBF6 
PNU7* WAlTR N4iPNL7. 

BRN PNU6, 

PNBF6J WORD 14.,Q»14, 

BCI X ERROR IN CODEX 
PM . 6 1 RTS R3 
I 

} END OF PNCV 

I 

i 

; SUBROUTINE PNDC 
l 

PNDC I CLR R4 
CLR R7 
TSR #5,R5 
CLR R6 . 

TSR PN BF »R 2 
, ADO #2*R2, 

PN LI S * BTSR (R2)*,R7 
ADD R7»R4 ... 



DEC 
BRZC 
PM. 10 l CMP 
SRSS 
PKL12! SUB 
ADD 
8RN 

PNLlii ADD 
CLR 
CMP 
BRSC 
ACE 
TSR 
8TSR 
TSR 
TSR 
TSR 

PNL13 sBTSR 
DEC 
BRZC 
R TS 

TEh * WORD 
CNEJ word 
zero: word 


R5 

Pt\L15 
R 4 , TE N 
PNLll • 

TEN »R4 
ONE# R6 
PNL1Q 
R6#R4 
R6 

R4,TEN 
PNL12 
ZERO ,R4 
PNBUP#R2 
R4*7(R2) 

#7 #R5 
PNBF,R6 
PN BU F, R7 
(R6 )♦ * <R7 )* 
R5 

PNli.3 

R3 

10. 

1 

60 


END OF PNDC 


I subroutine YNCON 

i 

YNCON: BCMP #131* YNBF 
BRZS YNL4 
BCMP #116. YNBF 
BRZS YNL6 
NMI SWRITE N3» YNBF5 
YM.20I WAITR N3.YNL20 
BRN YNtl 

YNBF5* WORD 35,0,35 
BCI % INCORRECT INPUT# NOT Y OR N St 
EVEN 

YNL4* BTSR #377, YNBF 
BRN YNU1 
Y M. 6 1 CUR YNBF 
YNUlt RTS R2 
YNBF I BYTE 0 
EVEN 
I 

I END OF YNCON 


SUBROUTINE YEARUIHITS 


YRLIMi TSR 
TSR 


#YRUU»R3 

#YRUC#R4 



TSR 

#YLBF,R5 

BCMP 

< R3 ), (R5) 

BBSS 

YLLl 

BCMP 

IRS), (R5) 

BRZC 

YLL2 

BCMP 

1 <R3) ,1 <R 5 > 

8RSS 

YLLl 

YLL 2* BCMP 

<R5>, (R4) 

BRSS 

YLL 3 

BCMP 

<R5>, (R4> 

BRZC 

YLL4 

BCMP 

1 <R5) ,1 <R4) 

SPSS 

YLL3 

BRN 

YLL4 


YLLl: SWS ITS N4, YLBF1 
YLLSi WAITR N4 *YLt 5 
STOP 

JMP YLL4 

YLBFlS WORD 44*0,44 

BCI XTHE YEAR VALUE EXCEEDS UPPER LIMIT* 

BYTE 15,12 
EVEN 

YLL3i SWRIT6 N4,YLBF2 
YLL6S WAITR N4,YLL6 
STOP 

JMP YLL4 

YLSF2S WORE 42,0,42 

BCI XTWE YEAR VALUE BELOW lower limit* 

BYTE 15,12 
EVEN' 

YLBF* WORD 2,0,2 

ss 

YLL 4* RTS R2 
YRULI WORD 0 
YRLL* WORD 0 

I END OF YEARLIMITS 

i 

I 

I SUBROUTINE AREA-SELECT 

I THIS SUBROUTINE SElECts THE CYLINDER, SURFACE 
J AND SECTOR,. ON WHICH THE NEXT RECORD IS 
I TO BE WRITTEN 

I IT FIRST. CHECKS WHETHER THE SECTOR NO, HAS BECOME 
I GREATER tHAN.lQ, THEN It PUTS IT BACK TO 1 AND 
I INCREMENTS THE SURFACE NO, BY 1 WHEN THIS OCCURS, 
i NEXT If. CHECK? WHETHER THE SURFACE NO, EXCEEDS 
I IT THEN INCREMENT? THE CYLINDER NO* 

I BY 1 AND SETS THE. SURFACE NO, TO 0 
t AND THE SBCTOT NO, TO 1, 

ARSLCT* TSR R2,D 
TSR DIS,R2 
TSR #13, R3 
PLiOif LSI . R2 




DEC 

R3 


BRZC 

PL1Q1 


CMP 

#540 00 ,R2 


BRZC 

PUOQ 


TSR 

CIS.R2 


TSR 

#5,R3 

PU102I 

ASR 

R2 


DEC 

R3 


BRZC 

PL102 


CMP 

#11, R2 


BRZC 

PLl 03 


ADC 

#1,CYL 


TSR 

#1 »D IS 


JKP 

PL 10 0 

PU103I 

INC 

R2 


TSR 

#5,R3 

PU 10 4 s 

LSL 

R2 


DEC 

R3 


BRZC 

PLl 04 


INC 

R2 


TSR 

R2,DIS 

PL 10 OS 

TSR 

C, R2 


RTS 

R2 


| 

1 ENE 

1 OF AREA -SELECT 


I 


t 

IDISK I/O ROUTINES'. 

SgTiTSR #RER.02,##200 
CLR #*202 
TSR #ERR.0Q,204 
CUR ##2Q6 
RTS R4 

READ STSR #4107 ,•< 1) 

8RN Rfc 

KR ITEt TSR #4113, -( 1) 

RNiTSB #20 0, >#177456 
BRZS ft k . 

TSR #{R4 >♦, ##177452 
TSR #( R4 )♦ ,##177444 
TSR <R 4) +, ##1774 60 

TSR #{R4)+, ##177462 
TSR < !>♦, ##177454 
MIT , , 

R£R, 02 *CMP (1 )♦ , ( 1) +. 

SENSEI TSB #1i## 177456 
BRZC SENSE 
TSB #4 0000 ,##177456 
BRZS ERR *11 
RTS R4 
ERR' ill STOP 
ERR.OOlWQRD 0 
I 

I ■ . . 

I SUBROUTINE FOR CO KM AND* RE 6 1 ON -CHECK 

t ' ' ' ' ' 
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CGNCHK: ClR CMF 
CLR R3 

BTSR CQMBF1,R3 
BCMP # 11 6, R3 
BRZS CM121 
BCMP #105* R3 
8RZS CMU21 
BCMP #127, R3 
BCMP #123, R3 
BRZS CML21 
BCMP #103, R3 
BRZS CML21 

swrite n4, Cm err 

CML22J WAITR N4.CML22 
TSR #1 1 CMF 
CMl.21 * RTS R2 
CMEFll WORE 0 
CMERFi WORE 47,0,47 

BCI X THE COMMAND REGION IS GIVEN WRONGLY X 
BYTE 15,12 
EVEN 

CMF: WORD 0 
ccmbfi: word o 

i 

I END OF COMCHK 
I 
I 
I 

i 

* SUBROUTINE for DISK -WRITE 
I 

DWR: JMS R4, WRITE 

WORD CYL «D IS »DRBF, BC 

TSR #DRBF,P0RBF 

TSR NRPS1, NR PS 

INC DIS 

JMS R2,ARSLCT 

STOP 

RTS R2 

t 

I 

l BEGINNING OF SUBROUTINE PKGHEK 

PKCHEKl TSR PKN.R3 
TSR PKB.R4 
CMP #0,PKN 
BRZS PKL4Q 
PKtll TSR PKUR5 

TSR #BF3+B»RB 
PKL2I BCMP < R4 )* »< R4 )♦ 

BRZC PKL3 
DEC R5 

BRZC. PKl2 ... 

$ WRITE N4, PKERR 
PKL4I WAITR N4.,PKi.4 
S WRITS N4, BP 3 
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PKL 5! WAITR N4,PKL5 
STOP 

J MP PK L4 1 
PKL401 JMP PKL6 
PKERRj WORD 40*0,40 
BYTE 15,12 

BCI % DUPLICATION OF PRIMARY KEY % 

BYTE 15,12 

EVEN 

PKL3S ADD R5,R4 
DEC R3 
BR2S PKL6 
JMP PKL1 
PKL6! TSR PKL»R5 

TSR #BF3+6,R« , 

PKl 71 BTSR <R6)+,(R4)+ 

DEC R5 
BR2C PKL. 7 
INC PKN 
PKL41* RTS R2 
PKN I WORD 0 
PKL! WORD 0 
PKB! WORD 0 
I 

I END OF PKCHEK 


SUBROUTINE CONCQD 


COKCOCi 

i TSR 

R2*D 


TSR 

CMBF2.R2 


TSR 

CMBF3* R3 


TSR 

#2,R7 


TSR 

#22, R4 

CML 2 f 

CLR 

R6 

CHLll 

clr 

R5 


BTSR 

(R2)i,R5 


SUB 

#6 0, R5 


ADD 

R5 ,R6 


DEC 

R4 


BRZC 

CMLl 


DEC 

R7 . 


BRZS 

CML3 


BTSR 

RS* (R3)* 


TSR 

#11, R4 


BTSR 

R6» TEMP 2 


JMP 

CML2 

CML3I 

TSR 

#6 ,R 4 


TSR 

CMBF^R7 


ADD 

#3 7, R7 

CHL4! 

CLR 

R5 


BTSR 

( R7 >♦ ,R5 


SUB 

#60,R5 


ADD 

R5 ,R6 
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DEC R4 
BRZC CNL4 
BTSR R6,(R3> + 

CLR R5 

BTSR «4(R3),R5 
ADC R5#R6 
BTSR R6, <R3) 

TSR D»R2 
R TS R2 
CKBF2: WORD 0 
CKBF3J WORD 0 
TEFP2* WORD 0 
CCFBFj WORD 0 
,*,+60 
. I 

I END OF CQMCOD 

t 

t 

I 

i subroutine pr cf «q ua l« gr ad e- ch ec ki ng 

I THIS SUBROUTINE CHECKS FOR THE ALLOWABLE. RANGE OF GRADES 

1 the only allowed grades are a,b,c & D 

I 

I 

PGLCHK1 CLR R3 
CLR R4 
CLR PQF, . 

BTSR PQLBF,R3 
BCHP #104# R3 
BRZS PQL6 
BCMP #101, R3 
BRZS PQL6 
BCHP #102, R3 
BRZS PqL 6 
BCMP #103, R3 
BRZS PGL6 
SWRITE N4,PQERR 
PQL 5 1 WAtTR N4,PQL5 
TSR #1,PQF 
JMP PQL6 

PQERRt WORD 37,0,37 
BYTE 15*12 

BCI X THE GRADING CODE IS WRONG X 

BYTE IS* 12 

EVEN 

PQBFl WORD 15*0*15 
,*,*16 
PQL 61 RTS R2 
POLBF* WORD 0 
PGFl WORD 0 
) 

I END OF PQLCHK 
I • 

I ■ • 

! SUBROUTINE ARH&QN 
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I 

ARMCCM CLR R3 

BTSR ARMBFl, R3 
SUB #6 0, R3 
TSR #12, m 
MPY R3 ,R3 
TSR MQ #R3 
CLR R4 

BTSR ARMBF1+1, R4 
SUB #60, R4 
ADC R4,R3 
BTSR R3, ARMBFl 
RTS R2 

ARMBFl « WORD Q 
ARMBFl WORD 14,0,14 
,*.♦14 
I 

I END OF ARMCQN 
I 
I 
I 

t SUBROUTINE FOR FORE IS N* LANGUAGE CHECKING AND TRANSFERRING 
I IT FIRST CHECKS WHETHER THE LEVEL OF EXAM PASSED IS 
i WITHIN RANGE QR NOT , THE ONLY ALLOWED ONES BEING .1,2 * 3 
I IT ALSO COMPUTES THE POSITIONAL CHECKSUM AND APPENDS 
I IT TO THE END OF THE RECORD. 

i it also Transfers the data from the reader buffer 

I TO THE FOREIGN LANGUAGE BUFFER 

f 

FLCONI CLR R3 


CLR 

R5 

BTSR 

BF3+17,R3 

BTSR 

R3, FLBF+12 

SUB 

#61, R3 

BRSS 

FLL1 

ADD 

R3 ,R 5 

INC 

R5 

SUB 

#3 »R 3 

BRSC 

FLL1 

CLR 

R3 . . 

BTSR 

BF3tl5,R3 

BTSR 

R3,FLBF*10 

SUB 

#60, R3 

TSR 

#12, MQ 

MPY 

R3»R3 

TSR 

MQ *R3 

CLR 

R4 , ... 

BTSR 

BF3t^6#M 

BTSR 

R4.FLBF+11 

SUB 

#60, R4 

ADD 

R4 ,R3 

CLR 

R4 ... 

BTSR 

BF3t20,R4 

BTSR 

R4,FLBFH3 

SUB 

m* M 

TSR 

#12.4 MQ 
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FLBF* 

FLERR* 

FLL1* 

FLL3* 

FU2* 


MPY 

R4,R4 

TSR 

MQ,R4 

ADD 

R4,R3 

CLR 

R4 

BTSR 

BF3*21»R4 

BTSR 

R4# FLBF 

SUB 

#60, R4 

ADD 

R4,R3 

ADD 

R5,R3 

BTSR 

R3, FLBF ♦!§ 

BRN 

FLL2 

WORD 

15,0,15 


• * • ^1 6 

WORD 45, 0* 45 

jjC* * HIGHEST EXAM PASSED IS OUT of range X 

S WRITE N4, FlERR 
WAITR N4.FLL3 
STOP 
RTS R2 

I END OF FLCON 

I 

I 


) 

I SUBROUTINE HEDCQD 

I FROM INPUT BUFFER AS PLACED BY THE READER 
I TO THE MEDICALBUFFER * IT ALSO COMPUTES 
I THE DIGITWISE CHECKSUMS OF EACH OF THE BLOCKS 
I S,H,A,P,E SEPARATELY A$ WELL AS THE CHECKSUMS 
I OF THE FIELDS P*M»Y*V , 

I IT APPENDS THE. CHECKSUM OF THE BLOCKS AT 
I THE END OF EACH BLOCK AND THE CHECKSUM OF 
I EACH FIELD AT THE END OF THE RECORD I TSELF 
I R3 CONTAINS THE. ADDRESS QF THE INPUT STRING 

I IN THE READER BUFFER AND H CONTAINS THE ADDRESS THE OF THE POS 
* OF THE POSITION. IN MEDICALBUFFER WHERE THE 
I THE STRING IS TO BE MOVED 
I TEMP CONTAINS THE VALUE OF THE CHECKSUHMF0R 
I EACH BLOCK AND APPENDS IT TO THE END OF EACH 
I BLOCK AS IT IS PASSED* 

I P CONTAINS THE CHECKSUM OF THE PRJOD FIELD, 

f M CONTAINS THE CHECKSUM OF THE MONTH* FIELD, 

t Y CONTAINS THE CHECKSUM OF THE. YEAR FIELD, 

I V CONTAINS THE CHECKSUM OF VALUE FIELD9 

I 

MEDcODI TSR R2,D 
TSR #5,R5 
CLR R2 
CLR P 
CLR M 
CLR Y 
CLR V , ■ 

CLR TEMP , 

TSR SBFSnSiW 
TSR. JMCBF+lD.r** 1 * 
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HC|.2i CLR 

R4 

CLR 

R7 

BTSR 

(R3>+, R4 

BT SR 

R4 #( R6 )* 

SUB 

#60# R4 

BTSR 

< R3 )♦ ,R7 

BTSR 

R7, (R6) + 

SUB 

#60# R7 

ADC 

R7»R4 

JMP 

MCL3(R2) 

HCU3J ADC 

R4,P 

ADD 

R4 , T EM P 

ADD 

#2 0# R2 

JMP 

MCL2 

ADD 

R4 #M 

ADD 

R4,TEMP 

ADD 

#20# R2 

JMP 

MCL2 

ADC 

R4,Y 

ADD 

R4#TEMP 

CLR 

R4 

BTSR 

<R3)+,R4 

BTSR 

R4, <R6) + 

SUB 

#60#R4 

ADD 

R4»TEMP 

add 

R4,V 

BTSR 

TEMP. (R6) 

CLR 

TEMP 

CLR 

R2 

DEC 

R5 

BRZC 

MCi.? . 

BTSR 

P # < R6 )♦ 

BTSR 

M # < R6 >f 

BTSR 

Y,(R6)f 

BTSR 

V »( R6 )♦ 

JMP 

MCL1 

PI WCRD 0 

Ml WORD 

0 

Y? WORD 

0 

VI WORD 

0 

MCBFi WORD 

iOO.Q.iOQ 

t 8 *+100 

TEMPI WORD 

0 

MCLlt TSR 

D#R2 

RTS 

R2 


t 

I SUBROUTINE TO VALIDATE INST itytE OF COMMISSIONING 

. I , . 

INCVALl TSR #2# 83: 

. TSR liNCP'84 
IN CL 3! TSR CMSUF*R5 
TSR #3#R7 
TSR <R4) *# R6 . . 

INCL5I BCMP (R#)*»(R5 )♦ 

BRZS INC Li 



lie 



SUB 

#1 »R 3 


BRZS 

INCL2 


BRN 

IN CL 3 

jHfiii 

SUB . 

#1 *R 7 

BRZS 

INCL4 


BRN 

IN CL 5 

IN CD * 

WORD 

I NCI* INC2 

I NCI* 

8 Cl 

%1 NAX 

INC 2* 

BCI 

XOTSX 

IN CL 2* 

SWRITE N4, INCBF 

IN CL 6* 

WAIT* 

1 N4 * I NC L6 


STOP 



BRN 

INCL4 

jNCBF* 

WORD 

40*0*40 

BYTE 

15.1?, 


BCI 

X INST, OF COMM, 6 JVEN WRONGLY X 


EVEN 


IN CL 4* 

RTS 

R2 

cmbuf* 

WORD 

0 


END OF INCVAI 


SUBROUTINE QUAICODE 


Qalcodi 

1 TSR 

R2.0 


CLR 

GL TOT 


CLR 

GLTOTi 


TSR 

#2,R7 


TSR 

#OULBFnO,R6 


TSR 

GLBF.R2 

QLL2* 

TSR 

#2»R5. 

olui* 

CL* 

R4 

' 

CLR 

R3 


BTSR 

< R2 )♦ »R 4 


BTSR 

R4.IR6H 


SUB 

#60* R4. . 


ADD 

R4*QLT0T1 


TSR 

#12. MQ 


HPY 

R4.R4 


TSR 

MQ*R4 


BTSR 

<R2 >*»R3 


BTSR 

R3» CR6) ♦ 


SUB 

#60, R? .. 


ADD 

R3 iQLTOTl 


ADD 

R3*R4. 


ADD 

R4.GLT0T 


SUB 

#1«R5 


8RZC 

GLL1 


SUB 

#1 »R 7 


BRZS 

QJJU3 


CUR 

R3- . 


BTSR 

<R2)t,R? 


8 TSR 

R3* fR6> + 


StiB 

#60»R3 
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ADD R3,QUT0tl 
ADD R3 iQLTOT 
BRN QLL2 
OUTOT* WORD 0 
OtToTlt WORD 0 
I 

QLL32 BTSR QLTOT»<R4>* 

BTSR QUTOT1, (R6) + 

TSr D,R2 

0 TO 09 

QULBFI. WORD 0 
**•♦3 0 

QLBF? WORD 0 
2 

2 END OF QUALCCDE 
2 

1 

1402 NOP 

2 THIS COMPLETES THE INPUT SECTION 
END 


2 .... 

2 THE SUBROUTINES USED IN THE OTHER STASES Of DATA VALIDATION 

1 these routines are complimentary routines to the subroutines used in. t ; 

2 INPUT STAOE AND ARE TO BE USED IN THE RETRIEVAL OF ThE INFORMATION FRO:*; 

2 THE RELATIONS ... .:>■ 

2 THESE SUBROUTINES WERE TESTED UNDER SEPARATION SQ THEY MAY NEED SLIGHT.; 
2 RECONDITIONING AS TO POSITION AND VARIABLES AND LABELS S 

2 

1 

2 SUBROUTINE 81 N«TO*ASC II 
81 NA SC l CLR R3 

TSR BA 8UF# R5 
CLR MO 
BTSR B A8 F * MQ 
TSR #144»R4 
DIV R4 #R3 
BCHP #0#,MQ 
BRZS BALI 
ADD #60# MQ 
BTSR MQ# <R5) ♦ 

JMP BAL3 

BAL12 BTSR #60#(R5>* 

BAL32 TSR R3#MQ 
CLR RS 
TSR SI 2# R4 
DIV R4#R3 
BCMP #0#MQ 
BRZS BAL2. 

ADD #6Q»MQ 
BTSR MQ# (RS)* 

UMP BAL4 , 

BAL22 B.TSR #60#<R5)t 
BALA 2 ADD #S0. RS . 



BTSR R3* (R5> + 

RTS R2 
babf* BYTE Q 
EVEN 

BABULS WORD 0 
I 

I END OF B!N«TOASCU 


I 


END OF MEDCQD 


SUBROUTINE MEDVAL 


I THIS SUBROUTINE VALIDATES THE BLOCKS AND FIELDS OF 
l THE MEDICAL FILE OF OFFICERS BY VALIDATES 
t THE CHECKSUMS CALCULATED BY THE MEDCQD ROUTINE 
I OF THE BLOCKS AS NELL A$ THE CHECKSUMS OF 
t AND APPENDED TO THE 8 POSITIONS AT THE END 

I EACH TYPE OF FIELD AT THE END OF THE RECORD 
i 

I 


MEDVAL I TSR 

R2.D 

CLR 

R2 

CLR 

R7 

CLR 

TEMPI 

CLR 

SS 

CLR 

HH 

CLR 

AA 

CLR 

PP 

CLR 

EE 

CLR 

SF 

CLR 

HF 

CLR 

AF. 

CLR 

PF 

CLR 

EF 

CLR 

PRF 

CLR 

PI 

CLR 

Mi 

CLR 

Yl 

CLR 

VI 

t Sr 

#20*R6. 

TSR 

#MCBF+i6*R2 

MVL3} CLR 

R3 

MVL1I CUR 

R4 

CLR 

R5 . , 

BTSR 

(R2 )♦ »R4 

SUB 

#60»R4 

BTSR 

<R2)+,RS 

SUB 

#68«RB 

ADD 

RSiRf 

UMp , 

MVUIR3) 

MVL2I ADD, 

-R4*Pi 




ADO 

R4 »TEM PI 


ADD 

#2Q« R3 


JMp 

MV Ul 


add 

R4 ,M1 


ADD 

R4, TEMPI 


ADC 

#2 Q» R3 


JMp 

MV Ul 


ADD 

R4 ,Y 1 


ADD 

R4#TEMP1 


CUR 

R4 


BTSR 

( R2 )♦ »R4 


SUB 

#6 0 * R4 


ADC 

R4 iVl 


ADC 

R4, TEMPI 


CUR 

R5 


BTSR 

(R2 )♦ »R5 


BCMP 

TEM PliRS 


BRZC 

MU70 

MVU26I CUR 

TEMPI 


SUB 

#4,R6 


BRSC 

MVU3 


CUR 

R4 


BTSR 

( R2 >+ #R4 


BCMP 

PI# R4 


BRZC 

MU53 

MVU40* CUR 

R4 


BTSR 

( R2 >♦ ,R4 


BCMP 

Ml# R4 


BRZC 

MU52 

MVU521 

CUR 

R4 


BTSR 

* R2 )♦ #R4 


BCMP 

Yl# R4 


BRZC 

MU57 

MV 1.64* 

CUR 

R4 


BTSR 

( R2 )+ »R4 


BCMP 

VI# R4 


BRZC 

MU67 


JMP 

MVUU 

ML53I 

JMP 

MVU4 

Ml.521 

JMP 

MVU5 . 

MU70* 

JMP 

MVU2KR6) 

ML67I 

JMP 

MVU7 

MU37I 

JMP 

MVU6 

MU73I 

JMP 

MVU47 

ML71I 

JMP. 

MVU43 

ML72* 

UMP 

MVU45 

M VI 211 JMP 

MVU22 


JMP 

MV U23 


JMP MVU24 
JMP MVU23 
TSR TEMPI, S8 
TSR #i#?F 
JMP MVU2S 

MVU22* TSR TEMP*# EE 
TSR #i,ff 
JMp MV 1,2 6 



MV 12 3* 

TSR 

temp i,pp 


TSR 

#1 ,PF 


JMP 

MVL2 6 

MVL 24 

* TSR 

tempi ,aa 


TSR 

#1#AF 


JMP 

MV 1,2 6 

MVL25* 

TSR 

TEMPI, HH 


TSR 

#1»HF 


JMP 

MVL2 6 

ML65* 

JMP 

MVL61 

ML7 7? 

JMP 

MVL5 7 

ML7 6* 

JMP 

MVL57 

MLSOs 

JMP 

MVL35 

ML7 4* 

JMP 

MV LSI 

ML7 5* 

JMP 

MVL5 3 

ML54* 

JMP 

MVL41 

MLS 5* 

JMP 

MVL3 7 . 

M VI. 4* 

CMP 

#1#SF 


8RZS 

MVL 27 

MVL3Q* 

CMP 

#1#HF 


BRZS 

MVL31 

MV 13 2* 

CMP 

#1,AF 


BRZS 

MVL 33 

MVL34I 

CMP 

#1»PF 


BRZS 

ML50 

MVL36* 

CMP 

#li|F 


BRZS 

ML55 


BTSR 

P1#*»2(R2) 


JMP 

MVL4 0 

MVL5* 

CMP 

#1,SF 


BRZS 

MLS 4 

MVL42* 

CMP 

#i.hf 


BRZS 

ML71 

MVL44I 

CMP 

#1,AF 


BRZS 

ML7 2 

MV 14 6* 

CMP 

#1 #PF 


BRZS 

ML7? 

MVU5 0* 

CMP 

SliBF 


BRZS 

ML74 , 


BTSR 

Ml# <*2 (R2) 


JMP 

MVL52 

MVL6I 

CMP 

#1»SF 


BRZS 

ML75 

MV i.5 41 

CMP 

#1 #HF 

• 

BRZS 

ML7S 

MV 1.561 

CMP 

#1 »A F 


BRZS 

ML77 

MV 1,6 01 

CMP 

#1#PF 


BRZS 

ML6S 

MVL62* 

CMP 

#i,|F 


BRZS 

MU 6 . 


BTSR 

V it *8 (R 2) 


JMP 

MvU$ 

M VJ. 71 

CMP 

#1.$F , 


BRZS 

ML6$\ 

MVL66I 

CM* 

BiiHF 
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BRZS 

ML61 

MVL7 0I 

CMP 

#1 »AF 


BRZS 

MLS 2 

MVL7 2I 

CMP 

#1 #PF 


BRZS 

ML63 

MVL74J 

CMP 

#1»EF 


BRZS 

MLS 4 


BTSR 

VI# -2 <R2) 


JMP 

MVLU 

MVL2 7* 

SWRITE N3» MVSP 

ML 1! 

WAITS 

t N3 iMLl 


TSR 

#1 #PRF 


JMP 

MVL3 0 

M L6 £« 

JMP 

MVL71 

MLSll 

JMP 

MVL67 

M U6 08 

JMP 

MVLS5 

ML6 3* 

JMP N 

'VL73 

ML648 

JMP 

MVL75 

MLS St 

JMP 

MVLS3 

MVL31I 

SWRITE N3.MVHP 

KL2* 

WAITR 

! N3»ML2 


TSR 

#1 iPRF 


JMP 

MVL32 

MVL33I 

SWRITE N3»MV AP 

ML 3 8 

WAITS 

! N3#ML3 


TSR 

#1#PRF 


JMP 

MVL34 

HVL35* 

SWRITE N3,MVPP 

ML 4 8 

WAITR 

! N3.#ML4 


TSR 

#1,PRF 


JMP 

MVL3S 

MVL37! 

SWRITE N3.MVEP 

ML 51 

WAITR 

N3»ML5 


TSR 

#1#PRF 


JMP 

MVL40 

MVU41* 

SWRITE N3.MVSM 

MLSt 

WAITR 

! N3.MLS 


TSR 

#1,PRF 


JMP 

MVL42 

MVL43* 

SWRITE N3*MVHM 

ML 7* 

WAITR 

N3 »ML7 


TSR 

#l.PRf 


JMP 

MVL44 

MVL458 

SwRlTE NSiMVAM 

HU0l 

WAITR 

N3.»ML1 0 


TSR 

#1,PRF 


JMP 

MVL46 

HVL47I 

SWRITE N3.MVPM 

MLlli 

WAITR 

N3*MLU 


TSR 

#1#PRF 


JMP 

MVL50 

MVL51I 

SWRITE N3.MVEM 

MLi2| 

WAITR 

. N3*ML1* 


TSR 



JMP. 

MVLS2 

MV L5 38 

SWRITE N3*.MV$Y 
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MLl3t WAITR N3 »M LI 3 
TSR #1,PRF 
JMP MVL54 

MVLSgt S WRITE N3.HVHY 
H LI 4] WAJTR K'3 iML 14 
TSR #l,PRF 
JMP MVL56 

MVL57: SWRJTE N3,MVAY 
M Ll 5: WAJTR N3»ML15 
TSR #1,PRF 
JMP MVUO 

PVU1S SWRITE N3, MVPY 
MLl6t WAJTR N3»Mtl6 
TSR #1,PRF 
JMP MVL62 

MVL63S SWRJTE N3.MVEY 
Mtl 7* WAJTR N3 »M Ll 7 
TSR #1 # P RF 
JMP MVL64 

MVU6S* SWRJTE N3,MVSV 
ML2 Ot WAJTR N3#M12Q 
TSR #1,PRF 
JMP MVL66 

MV 16 7 1 SWRJTE N3.MVHV 
MLS It WAJTR N3.ML21 
TSR #1#PRF 
JMP MVL7 0 

MVL7U SWRJTE N3,MVAV 
ML22I WAJTR N3#ML22 
TSR #1,PRF 
JMP MVL72 

MVL73I SWRITE N3.MVPV 
ML23t WAITR N3*ML23 
TSR #1,PRF 
JMP MV 17 4 

MVL7S* SWRJTE N3.MVEV 
ML24I WAJTR W3..ML24 
TSR #1 #RRF 
JMP MVLll 
MVLUt CMP #1,PRF 
BRZC MVL76 
SWRJTE N3,MCBF 
MVL77I WAJTR N3»MVL77 
MVL76* TSR D# R2 
RTS R2 
SSI WORD 0 
HHt WORD 0 
A At WORD 0 
PPt WORD 0 
E El WORD 0 
SFt WORD 0 
HFt WORD 0 
AFi WORD 0 . 

PFt WORD 0 
E.Fl WORD 0 
PR Ft WOR D 0 



TEMPI* 

WORD 

0 


MVSPt 

WORD 

31*0,31 



BOX 

P UP M 

XS -BLOCK, P-VALUE 

CORRUPTEDX 

kvwf: 

W Vbl> 

WORD 

31,0,31 



8 Cl 
EVEN 

%h -block, p-value 

CORRUPT ED X 

VA F * 

W CRD 

31,0,31 



BOX 

EVEN 

XA -BLOCK *P -VALUE 

CORRUPTEDX 

KVPPj 

WORD 

31,0,31 



B Cl 
EVEN 

XP -BLOCK, P-VALUE 

CORRUPTEDX 

KVEPJ 

WORD 

31,0,31 



8CX 

EVEN 

XE -BLOCK, P-VALUE 

CORRUPTEDX 

K VS P : 

WORD 

31.0,31 



B Cl 
EVEN 

XS-BLOCK,M -VALUE 

CORRUPTEDX 

KVHMJ 

WORD 

31, 0,31 



BOX 

EVEN 

XH-BLOCK.M -VALUE 

corrupted* 

HVAPj 

WORD 

31*0, 31 



BOX 

EVEN 

XA-BLOCK,K-VALUB 

CORRUPTEDX 

MVP Hi 

WORD 

31,0,31 



BOX 

EVEN 

XP -BLOCK,? -VALUE 

CORRUPTEDX 

MVEP.j 

WORD 

31,0,31 



B Cl 
EVEN 

xe-block,m-value 

CORRUPTEDX 

PVSYS 

WORD 

31,0,31 



BOX 

EVEN 

xs-block«y -value 

CORRUPTEDX 

M VH Y* 

WORD 

31, 0,31 



B Cl 
EVEN- 

xh-block,y -value 

CORRUPTEDX 

MVAYi 

WORD 

31,0,31 



BOX 

EVEN 

xa-block,y -value 

CORRUPTEDX 

PVPYj 

WORD 

31,0,31 



BOX 

EVEN 

XP-BLOCK,Y-VALUE 

CORRUPTEDX 

MVEYi 

WORD 

31,0,31 .. 

CORRUPTED* 


BCX 

EVEN 

XE -BLOCK, Y-VALUE 

MVS Vi 

WORD 

31,0,31 

corrupted* 


BCX 

XS -BLOCK, V-VALUE 

MVHVi 

EVEN 

t * 

WORD 

31*0,31 

CORRUPTED* 


BCX 

EVEN 

%h*block»vvalue 

MVAVi 

WORD 

31,0,31 

CORRUPTED* 

BCX 

XA-BLOCK*V-VALUE 

NVPV* 

EVEN 



WORD 

31,0,31 
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SCI XP-BLOCK#V"VALUE CORRUPTED* 
EVEN 

tfVEVj WORD 31*0,31 

Bel *E -B LO CK ,V *V AL gE CQRRUpTg)* 
EVEN 

Y1 : WO RD 0 
Vis WORD 0 
Pis WORD 0 
Hi: WORD 0 

t 

t END OF MEDVAl 

I 

i 

l END OF MEDVAL 


subroutine fleec 


fldeC: 

TSR 

R2»D 


CLR 

R3 


CLR 

R5 


CLR 

R4 


TSR 

#2 #R6 


TSR 

#F LB Ff 16,R3 

FU.4: 

8 TSR 

( R3 )♦ ,R4 


SUB 

#6 0* R4 


TSR 

#1 2, MQ 


MPY 

R4,R4 


TSR 

MQ#R4 


BTSR 

(R3)*,R5 


SUB 

#60, R5 


ADC 

R3.R4 


DEC 

R6 


BRZS 

STOP 

FLL5 


CLR 

R5 


BTSR 

(R3>*»R5 


SUB 

#60* R5 


ADD 

R5,R4 


CLP 

R5 


JMP 

FLL4 

fler: 

WORD 

20, 0, 20 

BCJ 

x data corrupted 

flls: 

CLR 

R5 


BTSR 

STOP 

(R3 )* R5 


BCMP 

R5,R4 


8RZ8 FLL6 
, SNR If £ N3 kFLER 
FLL7I NAITR N3.FM.7 
SNRITE N3,FlBF 
FLL1 01 HAS TR N3.FLL10 
FLL6I RTS R2 
I 

I END OF FLDEC 

f ■. "f i ' . > ' 



i SUBROUTINE QUALVAL 


i 


galval: tsr 

R2.D 

CLR 

QLVAL 

TSR 

#QULBF +16. R3 

TSR 

#2,R6 

CLL4I TSR 

#2,R7 

CLUS: CLR 

R4 

CLR 

R5 

BTSR 

( R3 )♦ »R 4 

SUB 

#6 O. R4 

ADC 

R4.R2 

TSR 

n 2». MQ 

MPY 

R4.R4 

TSR 

NQ.R4 

BTSR 

( R3 )♦ .R5 

SUB 

#6 0, R5 

ADC 

R5.R2 

ADD 

R5 ,R 4 

ADD 

R4, QLVAL 

SUB 

#1 ,R7 

BRZC 

QLL5 

STOP 


SUB 

#1 #R6 

BRZS 

QLL6 

CLR 

R4 

BTSR 

< R3 )♦ ,R4 

SUB 

#60»R4 

ADD 

R4.R2 

ADD 

R4, QLVAL 

STOP 


JMP 

CL L4 

GLVALI WORD 0 

GIL 6: CLR 

R4 

BTSR 

( R3 )♦ »R 4 

BChP 

R4. QLVAL 

BRZS 

QLL7 

CLR 

R4 

BTSR 

IR3J.R4 


BCNP R2,R4 
BRZS QLL12 
SWRITE N3.Ql.ERR 
GLL10* WAITR N3.QLL10 

BTSR QUtBF*25 # BABF 
TSR #QUL8F+25. BABUF 
JK8 R2.BINASC 
BTSR R4.BABF 
TSR #QULBF*3 QiBABF 
■ JM$ R2.BINAS0 
SWRITE N3.QMLBF 
GLUlt WAITR N3.Q.LLii 
BRN QLL.7 

QUU12* BTSR QLVAL. QULBF+25 
BRN QLL13 . 

QLL7I BTSR R2#(R3l 
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FTS R£ 

OLERH* WORD 20 * 0 1 20 

6 Cl % SATA CORRUPTED % 

Hi V.GRE 0 

i 

i END CF QUALVAL 

# 

« 

? SUBROUTINE YNCE CONVERT 


ykeeccs tsr 

R2» D 

TSR 

#10 i R3 

CLR 

R4 

YNL12: BTSP 

A# YN8F 

bRZS 

YNL13 

ADD 

#li.R4 

YK LI 3 x DEC 

R3 

3KZS 

YNL14 

BRCL 

YNBF . 

8Rn 

YNL12 

y k u4: sub 

#5,R4 

BBSS 

YNL15 

BTSR 

#»Y,YNBF 

Bm 

YNL16 

YMISi a TSR 

#*N,YNBF 

YM.16! BTSR 

YNBF, YNBF3+6 

SwRITE N3# YNBF3 

YMlV! WAIT* 

! N3»YNL17 

RTS 

R2 

A: BYTE 

200 

even 

t ! WORD 

I 

i EM 

0 

i OF YNCE CONVERT 

J 

OCPCEC: TSR 

R2»D 

CLR 

CP DF 

CLR 

CKMF 

CLR 

TEMP3 

TSR 

CRBF4.R2 

TSR 

CKBF5»R3 

TSR 

#2 »R7 

TSR 

#22*R4 

CPL5I CLR 

R6 

C1^L6S CLR 

w 

BTSR 

<R2)*#R5 

SUB 

#60» R5 

ACC 

R5,R6 

DEC 

R4 

BRZC 

CML6 

STOP 

DEC 

R7 

BRZS 

CML7 

BTSR 

R8,TBMP3 

. T SR 

#11#R4 

4RP 

CML5, 

Cl*L7« TSR 

#6,R4 
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TSR CMBF4.R2 
ADC #37. R2 
CM LI Q ! C LR R5 

BTSft < R2 )+ ,R5 
SUS #60. R5 
ADC R5.R6 
CEO R4 
SR2C CKL10 
CLR R7 

tTSR (R3)+,R7 
BCMP TEMP3.R7 
3RZS CMLll 
TSR #1»CMDF 
CKL11* CLP R7 

5TSR <R3)+,R7 
8GWP R6.R7 
tPZS CML12 
TSR #1* CMMF 
CPUS* CLR R7 

RTSS <R3),R7 
ADD TEMP3.R6 
BCKP R6.R7 
BRZC CML13 
JMP CP-L14 
CP LI 3 : CMP #1 .CMDF 
BR2S CKL15 
CMLie: CMP #1,CMMF 
3RZS CPL17 
BTSR R6,(R3> 

JMP CHL20 

C»L14i BTSR TEMP3 i-4(R3> 

sub temp3» R6 

BTSR R6» »2 IR3) 

JMP CML20 

CPUS* SWRITE N3, CD8F1 
CMLSi: WAITR N3.CMl.21 
SWRITE N3.C0MBF 
CML22 * WAITR N3.CML22 
JMP CML16 

CML17* SWRITE N3i CDBF2 
CKL23* WAITR N3.CML23 
SWRITE N3.C0MBF 
CML24* WAITR N3.CML24 
CPL2C* TSR C.R2 
RTS R2 

CMDF* WORD 0 . 

CMMF* WORD 0 

TEMP3I WORD 0 

CDBFli WORD 26*0,26 

BCl X ERROR IN DATE**FIELDS X 
CDBF2* WORD EQ.0,50 

SCI X ERROR IN. PC $*• OR ** J CO *»N CC *R N* CO RP S FIELD X 

BCI XERROR IN PC$*OR-JC-NfcC*RN«*CORPS FJEUDX 
EVEN 

CMBF4 I . WORD 0 
0KBF5I , WORD 0 



CflFBFi WORD 62,0,62 
. a, +6 0 
BYTE IS, 12 

EVEN' 



